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

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

S>>Тут хорошая стать и отличная картинка на эту тему -- https://blog.pragmatists.com/domain-driven-design-vs-anemic-model-how-do-they-differ-ffdee9371a86?gi=40c25922c8e9
S>По-моему — очередной булшит.
S>1. В нормальной, современной архитектуре нет никаких отдельных E и DAO. Это какой-то онанизм — сначала грузить из базы DAO, потом их превращать в E, потом обрабатывать, потом обратно превращать в DAO, и сохранять в базу.
S>Так никто не делает. Более того — чувак явно забыл о том, что есть ещё и DTO — ведь сервис общается и с клиентами. Поэтому полный ЖЦ этой халабуды выходит примерно таким: "получили DTO от клиента — отдали в сервис — тот преобразовал его в Е — поднял из базы пачку DAO — преобразовал их в E — как-то обработал — потом преобразовал часть E в новые DAO и сохранил в базу, а часть в DTO и отдал клиенту".

DTO тут совершенно ортогонален, чтобы показать отличия он не нужен.

S>2.
S>3. Опять же читаем статью, "the application with the anemic model has more repositories than the one with the rich model". Смотрим на картинку — автор врёт даже сам себе. На его же картинке с Anemic есть ровно 0 (ноль) репозиториев. Что, в общем-то, верно отражает современную реальность. Это в говно-DDD, которое он пропагандирует, нам нужны репозитории на каждый агрегат. А в современной анемик-архитектуре "репозиториев" примерно столько, сколько есть граней у сервиса. Скажем, вся бухгалтерия — это один "репозиторий", весь складской учёт — это ещё один; управление подписками — третий; human resources — четвёртый.
S>И при этом эти репозитории, в отличие от DDD, не содержат никакого императивного кода. Никаких там Find или Update, специфических для каждого типа Entity. Достаточно собственно DbContext, который описывает типы. Плюс, возможно, набор extension-методов к нему и к IQueryable, которые позволяют быстро компоновать между собой куски нужного функционала. Скажем, если нам надо часто вычислять средний чек по каким-то критериям, то мы можем отдельно построить функцию decimal Average(IQueryable<decimal> source), и в коде сервиса обращаться уже к ней, с уместными в каждом конкретном случае селектами.

Вы к каким-то деталям прицепились, дескать в анемичной модели у него не ноль репозиториев в анемике. Ну с его тз
DAO и есть простенький репозиторий. Повтрюсь, суть иллюстрации в связях между компонентами соотв. уровня. В один случае дизайна
архитектуры они допускаются, и даже не неизбежны, в другом (DDD) их можно избежать. Все, больше данная картинка не на что
не претендует. Неточностей там наверняка не мало, но главное отличие картинка отлично передает. В DDD вообще практически нету
зависимостей, сложность контролируема.