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

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

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

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

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

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

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

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

Покажи код.

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

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

G>>Ты комменты прочитай, нет необходимости в этом методе, достаточно написать T:class
V>Нет вообще никакой необходимости в этом коде, он лишний начиная с интерфейса. Код похож на подход "теперь я знаю лямбды" и соответственно всё можно описать с помощью лямбд.
С чего ты взял что нет необходимости? Как раз наоборот. Много сущностей имеют одинаковые аспекты — владение, видимость, права доступа, url slug, наличие имени итп.
Тебе придется все эти аспекты запихнуть в один EntityFetch и у тебя не будет проверки компилятором, в случае если сущность не поддерживает аспект. "Предельно конкретные наследники" EntityFetch у тебя не получатся, потому что одна сущность будет поддерживать аспекты владения и прав доступа, а вторая — наличие имени и url slug.
Интерфейсы комбинаторы выполняют тоже функцию, что и EntityFetch, только надежнее и меньше кода. Странно что ты утверждаешь что они лишние, тогда EntityFetch вообще не в тему, а его еще и руками разбирать надо *facepalm*


G>>Ты выше показываешь как раз "универсальный велосипед" со своим EntityFetch.
V>Он конкретный и простой, это просто набор параметров.
Ага, не проверяемый компилятором, который надо вручную разобрать. И который со временем распухнет для неральных размеров. Даже если ты сделаешь по одному EntityFetch для каждой сущности, то проблему это не решат из-за повторяющихся аспектов у тебя появится копипаста. А если по одному EntityFetch на запрос, то это банально хуже обычных методов, потом что в методах компилятор проверяет наличие параметров.

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

Без проекций будет тормозить. Любой способ работы с базой без проекций не жизнеспособен на практике.
Как ты будешь проекции описывать со своим DataFetch? И какой тип ты при этом будешь возвращать из методов репозитариев?

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

V>С чего такая уверенность?
Рецепт эффективного запроса — предикат с высокой селективностью и проекция. Ты пока не показал ни того, ни другого.

V>Запросы находятся в одном месте, их легко отлаживать и при необходимости изменить.
Расскажи нам кк легко отлаживать запросы, которые в одном месте? помоему для отладки запросов надо в SQL Profiler смотреть, а не в репозитарий.
Кроме того, если у тебя запросы на 50% повторяются, то ты не будешь применять декомпозицию linq, а будешь копипастить? Если будешь декомпозировать, то у тебя запросы перестанут быть в одном месте.

Попробуй напиши код репозиториев для сценариев, которые я уже раз десять озвучил. Сам все увидишь.

V>Никаких IQueryable наружу не торчит и не надо постоянно глядеть как и где оно используется.
А с чего ты взял что надо куда-то глядеть? Какие вообще проблемы могут быть?

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

V>Кода меньше и он не тычит деталями реализации мне в лицо. "Эй, смотри! У нас есть IQueryable! Представь какие возможности открываются!"
Если ты повторяешь что кода меньше его меньше не становится. Ты уже придумал лишние классы, которые надо создавать и разбирать их в методах репозитария, с чего меньше кода станет? Наоборот, его больше получается. И с каждым твоим постом потенциальный объем кода растет, а надежность и производительность падает. Про детали реализации не понял какая проблема.