Antonariyа почему не Get(userId), а new AccountByUserSpecification не спрятать в Get?

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


AntonariyAccountByUserSpecification вообще какой-то мутный класс, чье название больше подходит для функции. нафига под каждый способ выборки (ByUserName, ByUserPenisSize) класс городить? GetBy1способ, GetBy2способ по-моему логичнее.

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

GetBy1, GetBy2 — особенность разработки новичков и нубов

AntonariyСоответственно AccountByUserSpecification тоже должен реализовывать какой-нибудь IAccount?

Не, он должен реализовывать что-то типа ISpecification<TEntity>. Где под TEntity подставляется Account, например.


AntonariyНе понял. "Мой репозиторий" это то, каким его представил я или каким он должен быть по твоим выкладкам, чтобы "благоприятным образом сказывался"?

Ну да, твой, ты предложил добавить GetBy1, GetBy2, это твоё видение, а не моё. По моим выкладкам я сказал, какому принципу это соответствует. С чем не согласен?


AntonariyНовичок и нуб это одно и то же :)

Неа. Новичёк это чувак с полным отсутствием опыта. Нуб это чувак, которого опыт ничему не учит и он продолжает оставаться на уровне новичка :)

test_taskа чем это не спецификация? тоже можно обернуть чем-то, и цепочки AND/OR строить

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

test_task,

Ещё лучше это абстракция запрос-обработчик, куда укладываются спецификации (объект-запрос), и прямой путь к разделению на читателя/писателя :)

test_taskа почему Вас так читатели/писатели интересуют? CQRS? читал об этом, но, не работал с этой архитектурой.

В данный момент мы активно используем DDD/CQRS/ES. Поэтому и интересует.

AntonariyЯ просто не понял, к какой из реализаций относится фраза "благоприятным образом".

Разумное следование принципам SOLID, мы говорили об одном из принципов.

test_taskможете тут прояснить? у меня с этим опыт только как настроить маппинг NH (там так можно), чтобы "документ и его табличные части все разом сохранились (у них есть тоже зависимые объекты)". про это?

С натягом да, про это. В EF/NH корни агрегации можно выделить лишь условно.

AntonariyА можешь дать сылку или набросать кратенький пример, раскрывающий смысл этого ISpecification<TEntity>. Хочу переделать под этот паттерн такой код:

Конкретно особенностей реализации, их довольно много. Большинство из них базируются на Expression внутрях, но не все.

Вот зачётный примерчик http://enterprisecraftsmanship.com/2016/02/08/specification-pattern-c-implementation/


AntonariyИ еще вопрос, связанный с этим кодом. IPQList<T> зависит не от интерфейсов, а от классов AjaxJsonGetResult и Paging, а это, насколько я понимаю, моветон. Или нет? Если да, то проблема в Paging (на AjaxJsonGetResult можно забить, это временная затычка пока студию не починят ):

Ну вот у тебя пример по сути что-то типа Query Object, только неудачный, так как используется сериализация в строку, что выглядит как костыль для возможности работать с веб-приложением. Сериализация/десреиализация это вопрос, решающийся на стыке клиент-сервер, посмотри на ModelBinder к примеру. Не нужно это просовывать внутрь своих сервисов. Ужасно тяжко поддерживать, отлаживать и развивать.

Paging может быть либо одним из комбинируемых спецификаций, либо базовой спецификацией. Результат запроса придётся также обобщить, так как тебе надо ещё общее количество элементов.

Интерфейс IPaging опять же, у тебя решает несколько задач, и вообще по виду призван обслуживать прикладные запросы клиентского кода. Его в сервисах тоже не должно быть, на мой взгляд. Результат запроса по пейджингу: это срез + общее количество элементов. А IPageabe это больше относится к view model, так информация HasNext/HasPrevious и проч. нужна для презентации, в логике она не нужна.


AntonariyОднако сделать зависимость IPQList от IPaging<TEntity> вместо Paging<TEntity> невозможно, поскольку Paging, реализующий IPaging<TEntity> немедленно требует конкретный <Entity>. Paging<TEntity> прекрасно справляется со всеми entity, и городить отдельный Paging для каждого entity совсем не хочется.

Не, конечно не надо этого делать. Речь-то шла о спецификациях, а не о результатах запроса. Репозиторий может выглядеть так:




Для пейджинга отдельный метод.

По моему же глубокому убеждение, методов, возвращающих коллекции репозиторий иметь не должен. Он должен уметь извлечь сущность из хранилища по ID, добавить и удалить. Всё.

Остальное уходит на роль IQuery / IQueryProcessor / IQueryHandler<IQuery> — это намного гибче и не надо ходить по скользкому краю, постоянно матерясь.

test_taskhVosttPaging может быть либо одним из комбинируемых спецификаций, либо базовой спецификацией.

на мой взгляд, Paging, не относится к спецификации

Я предложил ниже вариант, где не относится. Но если обобщить результат запроса, то можно и сделать спецификацией. Не вижу проблем.

test_taskтут кроме гибкости добавляется еще б о льшая уверенность в том, что ОРМ сгенерит "нужный SQL" (спецификация тут может подводить). но этот шаблон фактически означает написание готовых параметризированных запросов под разные, возможно, схожие цели

Спецификация не отвечает за генерацию нужного SQL, за это отвечает провайдер. В случае EF, это LINQ провайдер. Поэтому подводить она не может.