Здравствуйте, gandjustas, Вы писали:

G>Какая от этого польза? Вред мы уже видели, а польза где?

Декомпозиция. Следование принципу "разделяй и властвуй".

G>У тебя получается более сложный код. Потому что потребитель твоего репозитария вынужден формировать класс DataFetch, а внутри репозитария надо этот DataFetch разбирать и собирать Linq запросы. Так еще и статической проверки DataFetch нету.
G>Не веришь? так попробуй реализовать сценарии, которые я приводил:
G>1) Показывать посты по дате добавления
G>2) Показывать посты по количеству оценок за день (самые популярные)
G>3) Показывать посты по комментов за день (самые обсуждаемые)

G>Сравни с объемом кода, скоростью разработки и затратами на поддержку без репозитариев

Наследник DataFetch всегда предельно конкретный, там не 100500 фильтров и метод выборки занимает полэкрана. И этот код легко читать и поддерживать.

G>Я могу легко создать десятки интерфейсов-аспектов и комбинаторов к ним, а ты все поместишь в EntityFetch ? Прости, но такое решение будет неюзабельным совершенно. Да и какая гарантия в твоем коде что сущность вообще поддерживает нужный аспект? Никакой. Поэтому получаем больше ошибок и больше кода.

Проблема в том, что тебе не нужны "десятки интерфейсов-аспектов" в твоём приложении. Ты тратишь впустую время на универсальные решения.

G>Ты комменты прочитай, нет необходимости в этом методе, достаточно написать T:class

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

G>Ты выше показываешь как раз "универсальный велосипед" со своим EntityFetch.

Он конкретный и простой, это просто набор параметров.

G>А проекция? как ты её задавать будешь? А нетривиальные фильтры?

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

G>Вот в этом и проблема. Значит запросы будут гораздо менее эффективными от применения репозитариев. А польза в чем?

С чего такая уверенность? Запросы находятся в одном месте, их легко отлаживать и при необходимости изменить. Никаких IQueryable наружу не торчит и не надо постоянно глядеть как и где оно используется.

G>Я вообще не понимаю где будет упрощение, если у тебя внутри репозитариев такой же Linq, но параметры ты передаешь через дополнительный (!) класс EntityFetch, с которым ошибиться на порядок проще. Кода больше, ошибок больше, где "простой как доска"?

Кода меньше и он не тычит деталями реализации мне в лицо. "Эй, смотри! У нас есть IQueryable! Представь какие возможности открываются!"