iT>>Не знаю, как насчет новой... Repository был описан в книжке Фаулера по архитектуре в 2003 г.
B>Разве? Не припомню. И с сайта Фаулера этот паттерн ссылается на книгу Domain Driven Design, а не Enterprise Patterns.

с. 341 в русском издании.

B>В случае Anemic Domain, в модель пихается только та логика которая модет быть ограничена строго этой моделью. Такой логики, обычно, в проектах не так много.

В "настоящем" Anemic Domain в модели логики вообще нет. Я не очень понимаю, что значит "логика которая модет быть ограничена строго этой моделью".

Я мыслю так:
При увольнении (Fire()) сотрудника должны быть заблокированы (IsActive=false) все его учетные записи в почте, например. Это логика домена. Она там есть всегда. Независимо от того, какое приложение работает — "главбух" или "директор". Если зацепили увольнение — логика отработает.

А если по кнопке в интерфейсе директора надо "найти всех сотрудников, проработавших меньше полугода и больше одного раза сменивших за время работы руководителя и всех таких — уволить после предварительного отображения списка, и разослать соответствующие письма" — это логика приложения

В Anemic Domain логика блокировки учетных записей будет внутри логики поиска и увольнения "скакунцов" или, может, будет явно включена каки-то вызовом вспомогательного shared метода.
А сами сотрудники будут не сильно умнее DataRow.

iT>>Если вы разделите бизнес-логику на логику домена и логику приложения, то станет видно, что первая — да, должна быть внутри, а вот вторая может быть и выставлена как сервис.
B>Не очень понял. Логика которая обращается к DAL, она какая из двух?

Ну, и та, и та может быть, по идее.

iT>>DAL — это не совсем внешний сервис, это скорее "внутренний сервис", он ближе к данным и, в принципе с ним могут работать и сами бизнес-объекты. Впрочем, тут есть разные подходы.
B>Да, могут, для этого делается абстракция "репозиторий". Только я хочу понять в чем кайф от такого подхода?

Кайф в том, чтобы когда тебе требуется новый хитрый поиск сотрудников, не нужно было писать еще один Employee[] GetMegaPuperEmployeeList(....) в DAL, у которого внутри зашит конкретный такой SQL, связывая классы AppLogic — DAL еще одной веревочкой. А можно было бы выразить этот запрос на языке объектов и пусть Repository выполнит. Фаулер, кстати, не говорит, а это очень интересно, что Repository может также несколько ИЗМЕНЯТЬ запросы, например, исходя из прав доступа текущего пользователя Добавлять свой аспект.
При этом "клиентская" логика об этом не знает и не заботится.