Gena_16032014Парамонпропущено...


А может все-таки это одна сущность, которая состоит из двух таблиц? )

суть вопроса не в том одна или две сущности, а как правильно код написать в этой ситуации. Есть репо для работы с одной таблицей есть репо для работы с другой таблицей...
Делать репо для joina или какие-то еще варианты?
Есть мнение, что, если данные в проект будут приходить только из БД, то никаких репозиториев делать не нужно, а можно обойтись голым ORM (EF, NHibernate и т. д.). Т. е. не усложнять там, где это не нужно, т. к. с репозиторием много проблем, и просто так они не решаются.

ПарамонGena_16032014 Есть репо для работы с одной таблицей есть репо для работы с другой таблицей...
Делать репо для joina или какие-то еще варианты?

Да. Делать репо для работы с сущностью, а не с таблицей. )
Хмм... Это как-то связано с понятием "корень аггрегации"? Если да, то автору темы лучше гуглить по "EF repository agregation root".

Gena_16032014А какие проблемы с репой. на конкретных примерах
Вот тут Монстрю ссылку дал. Если коротко, то проблема в разрастании репозитория(ев). Эта проблема вообще известна как класс проблем, возникающих во многих областях программирования. Название этого класса я не знаю. Но та же проблема возникает при, например, построении служб, когда нужно представить некий АПИ с запросами. Начинают клепать службы вида AddXXX, FindXXXById и т. п. Некоторые объединения в классы помогают, но всё равно возникают проблемы при сложных запросах со связями.

И насколько я понимаю, даже решения, предложенные по ссылки Монстрю, всё равно не обладают такой гибкостью и функциональностью, как хотя бы в EF вкупе с расшерениями LINQ.

Парамонuser7320Хмм... Это как-то связано с понятием "корень аггрегации"
Да.

А вообще это уже не раз обсуждалось.
У меня по этому корню ряд вопросов. Не обязательно к вам, а вообще к участникам дискуссии.

1. А всегда ли можно выделить корень аггрегации? Если нет, то что делать?

2. Два разных корня аггрегации могут пересекаться (т. е. иметь одинаковые сущности в составе)? Если да, то это нормально или это проблема и её надо как-то решать?

3. Может же быть, что количество корней аггрегации будет большим? Может, даже больше количества самих сущностей. Тогда снова упираемся в разрастание репозитория, наполненного кучей функций по работе с корнями аггрегации. Что делать?

Gena_16032014skyANAПриведите конкретный пример и лучше с кодом.
кода можно сказать нет.. я пока только думаю как лучше. Конкретный пример. Ну например есть интернет магазин . Таблица с предложениями. И с рубриками. Нужно выводить предложения на страницу с информацией по рубрикам. И в то же время нужно выводить рубрики отдельно. Ну выходит два репозитория в одном джоин 2х сущностей. В другом просто выборка из 1 одной сущности...
Если работа будет только с БД, достаточно одного EF (ну или какая ORM там лучше подойдёт для вашей БД).

skyANAА теперь представьте что данные Вы захотели получать не напрямую из базы, а через API сервис.
А действительно ли всё так плохо и всегда надо программировать с учётом "а вот если через 5 лет понадобится добавить работу с АПИ-сервисом, с тем, с другим, с десятым..."? Задача пока стоит из БД? Ограничиваемся одним EF. Как добавят работу с сервисом - новое ТЗ и дописываем до работы с сервисом. Кой смысл сразу лепить супер-универсальное решение, которого, кстати, не бывает?

Ну и, по-моему, работа с БД и с сервисом требует разного подхода. Не факт, что АПИ-сервис такой же функциональный, как EF. Скорее, он и третьей доли EF-функциональности не имеет. Значит, чтобы не ограничиваться самым малофункциональным элементом, надо будет написать отдельный репозиторий для работы с сервисом, и отдельный - для работы с БД через EF. Так?

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

monstrUskyANA,

можно столько всего сделать, что закачаешься.
люди же просят посоветовать с чего начать, как поступить.
ребята делайте для начала как можно проще - жизнь заставит и до фабрик дойдете , и до контейнеров
Люди просят нечто универсальное. Репозиторий в чистом своём виде - универсальное. Только в чистом виде он подходит только для очень простых случаев. Для сложных случаев начинаются подгонки и мутации репозитория для каждого типа случаев. В результате универсальность остаётся утопией.

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

monstrUuser7320пропущено...

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

репозиторий как паттерн задумывался как абстракция, которая скроет всю работу с БД для операций выборки, добавления, обновления для сущностей. на практике оказывается, что операций извлечений данных уйма, и не всегда понятно репозиторий к какой именно сущности делать.
Мне вот это кажется странным. Репозиторий как паттерн придумали явно не в 2000-х, а раньше. И, судя по тому, что проблемы с ним начинаются почти сразу же после начала использования (начал делать и тут же получил сотни методов типа FindById), почему о его проблемах стали говорить только недавно? Почему все эти QueryObject стали активно обсуждать только лет 5 назад? А до этого что, годами довольствовались километровыми списками методов репозиториев? Или каждый "зубр" писал свой велосипед, проклиная тех, кто придумывает "неработающие паттерны"?

skyANAuser7320, ну вот что ты несешь?

Я же сказал: два корня агрегации, два репозитория.
По поводу IQueryObject: я первый раз использовал этот шаблон еще при .Net 2.0, когда Linq и IQueryable в помине не было.
А есть случаи, когда репозиторий можно использовать в чистом виде, без всяких квири обджектов и прочих мутаций? Приведи пример, пожалуйста.

user7320skyANAuser7320, ну вот что ты несешь?

Я же сказал: два корня агрегации, два репозитория.
По поводу IQueryObject: я первый раз использовал этот шаблон еще при .Net 2.0, когда Linq и IQueryable в помине не было.
А есть случаи, когда репозиторий можно использовать в чистом виде, без всяких квири обджектов и прочих мутаций? Приведи пример, пожалуйста.
И когда это не приведёт к проблемам, которые описаны в блоге Бындю.

Парамонuser7320,

В принципе, поднимаешь правильные вопросы.
Есть там проблемы с пониманием и с реализацией, но есть задачи которые он решает.
Добавление абстракций приводит к некоторой потере в гибкости. За все нужно платить )
Я к тому, что, наверное, репозиторий сам по себе никогда не применяется и в чистом виде только в учебных статьях используется, типа этой . А этот дядька Фаулер, который этот репозиторий придумал (или всего лишь популяризовал?), об этом упомянуть забыл, похоже. Ну и заодно практически применимые мутации репозитория тоже не привёл, наверное (я его книжки не читал... но осуждаю, да). Поэтому спустя столько-то лет всякие бындю пишут статьи, как приготовить этот самый репозиторий по уму, и что в сыром виде он не съедобен. А раз до сих пор пишут, значит, общих выработанных подходов нет. Иначе бы не Фаулера с его репозиторием все рекомендовали, а Бындю с его мутациями репозитория.

skyANAuser7320пропущено...

А есть случаи, когда репозиторий можно использовать в чистом виде, без всяких квири обджектов и прочих мутаций? Приведи пример, пожалуйста.Что такое чистый вид? Ты вообще описание шаблона Repository смотрел? Видел картинку? Понимаешь что такое aCriteria?
Критерий - это условие отбора, как я понял. Т. е. (Person.Id == 1) - это вариант критерия.

skyANAuser7320пропущено...

А есть случаи, когда репозиторий можно использовать в чистом виде, без всяких квири обджектов и прочих мутаций? Приведи пример, пожалуйста.Что такое чистый вид? Ты вообще описание шаблона Repository смотрел? Видел картинку? Понимаешь что такое aCriteria?

Судя по тому, что у тебя сотня методов типа FindById, ни фига ты не видел и не разобрался. Но при этом разглагольствуешь про какие-то мутации

Вот тебе репозиторий без всяких мутаций в виде сотни методов:


Тут ещё вопрос, что понимать под критерием. Можно целый интерфейс, как вы, под него подвести.

skyANAuser7320пропущено...

И когда это не приведёт к проблемам, которые описаны в блоге Бындю.Какие конкретно проблемы ты решить не можешь?

У меня не возникало проблем, описываемых Бындю, потому как я изначально использовал шаблон "прямые ручки" и те подходы, что он предлагает в виде решения при реализации репозитория.

Бындю же не первооткрыватель паттернов проектирования
Так я и говорю - это зависит от того, что понимать под критерием. Одни делают кучу методов и критерий фактически жёстко инкапсулирован в каждый метод. Т. е. FindById - один критерий и один метод, FindByNameAndCity - другой критерий и отдельный метод для него и т. д. У вас же, как я понимаю, нечто более гибкое и критерий задаётся в параметре, а сам метод один для всех возможных критериев для данной сущности (или корня аггрегации) .

Но вот почему у вас несколько методов: Find, FindOne? Наверняка, и другие есть - типа Contains и других. А ведь надо ещё и вставки-удаления-обновления - короче, полный CRUD - реализовать. Т. е. методов в вашем подходе тоже немало - в средних БД за сотню уходит для полного КРУДа, наверное.

skyANAuser7320Но вот почему у вас несколько методов: Find, FindOne? Наверняка, и другие есть - типа Contains и других. А ведь надо ещё и вставки-удаления-обновления - короче, полный CRUD - реализовать. Т. е. методов в вашем подходе тоже немало - в средних БД за сотню уходит для полного КРУДа, наверное.Что ты хочешь сказать-то?

Обратимся снова к описанию шаблона: "A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection ."

А почему у List<T> несколько методов: Find, FindAll? А какие ещё методы есть у List<T>? А какие вообще методы работы с коллекциями есть? А как они реализованы в Linq? А какие параметры принимают? А какие есть реализации в других языках программирования, других решениях?

Вот тебе примеры и методов и критериев.
Я хочу сказать, а нельзя ли ещё усовершенствовать твой вариант? Вот у EF не просто Find, FindAll и пр., а сразу со связями всё - из одной сущности можно вытянуть связанные(ую) другие. А Find, FindAll и пр. - это всего лишь один из критерев отбора там - для множества или единственного результата. Т. е. сначала критерии по сущностям задаёшь, включая связанные сущности - т. е. фильтруешь данные, потом критерии множественности-единственности отбора. Вот как удобно!

Короче, я хочу работать с репозиторием, как с EF - написал context и пошёл вытаскивать объекты цепочкой методов или вообще LINQ-выражением. Я не понимаю, почему в EF всё удобно, а в этих ваших репозиториях какие-то извращения с QueryObject и прочим.

user7320Короче, я хочу работать с репозиторием, как с EF
Лучше так сказать: я хочу работать со всеми источниками данных, как с EF. Что мешает мне это сделать? Сложность реализации или что?

user7320user7320Короче, я хочу работать с репозиторием, как с EF
Лучше так сказать: я хочу работать со всеми источниками данных, как с EF. Что мешает мне это сделать? Сложность реализации или что?
Вот вы говорите "представь, что данные приходят не из БД, а из веб-сервиса". А я хочу с этим веб-сервисом работать как с EF - ЛИНКи там всякие, цепочки методов, лямбды. Что для этого надо сделать?

monstrUuser7320,

нет, ну тут ты разделяй - репозиторий и 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 операций.
Эта штука работает с корнями аггрегации? Если надо вставить не только сущность, но и связь этой сущности с другими сощностями (заполнить таблицы связей)?

monstrUuser7320пропущено...

Лучше так сказать: я хочу работать со всеми источниками данных, как с EF. Что мешает мне это сделать? Сложность реализации или что?
если ты хочешь работать с источниками данных - тебе для начала нужна реализация этого источника.
метод типа IList<Users> GetUsers().
вот и будет реализация твоего источника. где он реализован и как - работа для источника.
и чтобы web сервис загружал объекты со всеми связями - эту работу надо провести внутри источника.
Т. е. написать провайдер данных, который бы позволял отправлять веб-сервису всякие ЛИНКи и лямбды, которые этот веб-сервис бы умел "парсить" и превращать в запрос к БД, а потом возвращать обратно готовый результат запроса в виде объекта со всеми связями (корень аггрегации)?

skyANAuser7320пропущено...

Вот вы говорите "представь, что данные приходят не из БД, а из веб-сервиса". А я хочу с этим веб-сервисом работать как с EF - ЛИНКи там всякие, цепочки методов, лямбды. Что для этого надо сделать?Книжки почитать

Хочешь использовать в качестве Criteria выражение как в EF - используй! Какие проблемы? EF по твоему чудесно как-то устроен? Думаешь он каким-то мистическим способом преобразует "ЛИНКи там всякие, цепочки методов, лямбды" в запрос к БД?

Нет! Там тупо код написан. Используй в своей реализации подобный подход. Почитай про IQueryProvider.
Вот-вот, "там кода написан". Причём кода там написано может даже поболее, чем в "репозитории с двумя сотнями методов". Нужно свои провайдеры писать. А в EF для меня дяди написали и бесплатно дали использовать - красота!

А у вас, кстати, кретирий тоже из себя представляет некий Expression, как у Монстрю ? По идее, если писать в веб-сервисе не FindUserById(int userId), а FindUser(Expression predicate), то можно всякие ЛИНКи и лямбды прямо в параметр метода сервиса отправлять.

Вот тут - чего внутри IPersonCriteria сидит? Методы, принимающие Expression?