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