user7320skyANAПотому как репозиторий должен иметь интерфейс, что одинаково просто реализуется для разных вариантов распределения и хранения данных, тем самым обеспечивая persistence ignorance
А в интерфейсе как учесть всё разнообразие запросов, включая джойны и пр.? Через объект-запрос? Через составление сложных запросов из простых репозиторных?

репозиторий как паттерн задумывался как абстракция, которая скроет всю работу с БД для операций выборки, добавления, обновления для сущностей. на практике оказывается, что операций извлечений данных уйма, и не всегда понятно репозиторий к какой именно сущности делать.
недавно сдали сложный проект. наружу была web application. но нас предупредили, что все методы, отдающие данные, должны быть доступны через web сервисы.
с ребятами подумали, что выгодно нам будет иметь слой доступа к данным Facade. в нем реализовываем все методы, получающие данные. и наше основное приложение данные получает из этого слоя.
для web сервисов завели другое приложение - все данные загружаем из слоя Facade.
благодаря этому загрузку данных мы реализовываем только в одном месте.

теперь о том как реализовываем.
для выборки простых значений в конечном итоге надо сформировать выражение типа select * from myTable where id=12.
то есть разумно репозиторий реализовывать так, чтобы в нем можно было накапливать условия where.
для многих случаев будет достаточно. накопление where выражений в репозитории также реализовать можно.
но не для всех.
когда у вас много соединений с таблицами - набором нескольких where выкрутиться не получиться.
когда вы не знаете, какой корень агрегации выбрать.
то есть когда нужен вам список пользователей с ролью SuperUser - репозиторий чего вам нужно делать? пользователей или ролей?

мне пришлось репозиторий бросить и строить запрос напрямую.
но более практичным был бы подход делать объект-запрос. его покрыть тестами можно.

сейчас написал - выработалось правило :)
если вы можете однозначно сформулировать корень агрегации - пользуйтесь репозиторием.
если нет - пользуйтесь объектом-запросом

чем плох репозиторий человек отлично написал тут

skyANA,

можно столько всего сделать, что закачаешься.
люди же просят посоветовать с чего начать, как поступить.
ребята делайте для начала как можно проще - жизнь заставит и до фабрик дойдете , и до контейнеров

user7320,

нет, ну тут ты разделяй - репозиторий и QueryObject.
когда ты пользуешься репозиторием, использовать QueryObject нет большой необходимости.
фактически (если следовать концепции автора), то он в итоге хорошо подходит для реализации запросов вида
select * from myTable where id=123 или
select * from myTable where id in (1,2,3) [может быть exists] (последнее годиться если производительность запроса не страдает)

если у тебя более сложные запросы - надо смотреть по месту. вполне возможно прийдешь к QueryObject.
например методы типа FindUserByCity() я бы реализовывал в отдельном слое.
вопрос - использовать репозиторий или QueryObject для загрузки данных решал бы исходя из того, укладывается запрос с поиском в конструкцию
типа select * from myTable where id=123.
если да - реализовал бы при помощи репозитория.
если нет - использовал QueryObject.



вот интерфейс репозитория, который я применил в проекте.
при реализации работать так же удобно, как и в EF.
тут только запросы для отбора данных и CRUD операций.