LessypskyANAВы специально игнорируете упоминание CQRS?
3. Не использовать репозиторий, а использовать CQRS и никакого цементирования в методах сервисного класса.
отнюдь. Просто в CQRS у вас все равно будут вариации на тему зацементированности или репозиториев
А слабо пример привести?

LessyphVosttне будет зацементированности.

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

В случае с CQRS ЕF запросы будут инкапсулированны в отдельных классах, а не зацементированы в методах сервисного класса, чего бы это не значило

hVosttskyANAС точки зрения CQRS это будет команда, внутри которой вызов хранимой процедуры.

Если +ES, то конечно нет. Никаких хранимых процедур )
Это да, я просто думал, что у комрада Arpanx проблема как вызвать хранимку.

ArpanxskyANA
Ну да, я изначально и хотел/подумал "вот CQRS решение моих проблем", потом где-то тут же вычитал, "а спецификации можно комбинировать, а Query нет", думаю ну ладно, пусть будет Repository.
По поводу портянок SQL-кода (на 2500 строк, которые склеиваются на сервере приложения с помощью С# и скармливаются базе через ADO.NET), код который вычисляет какие-то абстрактные данные для отчетов, которые потом не требуют сохранения, думаю да заверну их в query object pattern . Думаю это было от большого ума написано. Нечего бизнес логику в SQL-е писать. Вполне можно разобрать на получение из Repository данных и логику написать на С#, так будет легче, понятней и можно будет тестировать.

Но все равно, есть же ситуации когда надо выполнить какой нибудь комплексный/сложный запрос, который абстрактный и не принадлежит ни к одной Entity, в таких случаях буду разрешать себе использовать DBContext (запросы Read-only), пока так.
Может конкретный пример приведёте?
А то ударяетесь с ходу в какие-то пространные рассуждения, из которых не понятно, а в чём конкретно проблема.

SQL код на 2500 строк, который вычисляет какие-то абстрактные данные для отчетов, знаете как можно упростить?
Вычислять эти данные при добавлении, изменении, удалении и сохранять. Потом отчёт строится очень быстро и элементарным запросом.

15 лет назад на первой работе научили

Arpanxя изначально и хотел/подумал "вот CQRS решение моих проблем", потом где-то тут же вычитал, "а спецификации можно комбинировать, а Query нет", думаю ну ладно, пусть будет Repository
А что нужно комбинировать-то? Какие-нибудь параметры? Дак в CQRS с этим проблем нет.

Arpanxв таких случаях буду разрешать себе использовать DBContext (запросы Read-only)
А чё не Dapper?

Arpanx,

и может вообще пора задуматься об OLAP?

ViPRosнапиши тест на вывод числе фибаноччи
В гугле забанили? "fibonacci unit test"