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

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

GZ>>ФАУЛЕР. Фаулер дал другую терминологию: Transaction Sript и Domain Model.
IB>Автор терминов Rich Domain Model и Anemic Domain Model — Фаулер.
+1
IB>Кратко говоря — Фаулер разбирая Domain Model говорит, что Rich — это правильная Domain Model, а Anemic — не правильная. Таким образом, к Transaction Sript это не имеет никакого отношения, если говорить о Фаулеровских терминах.
-1 Только не тебе, а Фаулеру. В книжке, в которой он полновесно хотел описать все паттерны, он вполне справедливо запутался. Если брать саму постановку вопроса — то Anemic и Transaction Script, одно и то же. Далее, после данной книги, когда оказалось что Transaction Script может описывать предметную область, а он это не учел, то тут и начался у него переполох в уме.
IB>Так что прежде чем писать про Anemic vs Rich, не плохобы написать, что такое вообще Domain Model, чего я добивался еще в прошлый раз.
Что такое модель предметной области? Она есть всегда и везде. Ибо по ней и создается архитектура.

GZ>>Под Domain Model некоторые понимают Rich Domain Model, что не является правдой,
IB>Это ты Фаулеру скажи..
Ежели смотреть обсуждения нескольких лет назад, то ему это уже говорили. Что и породило новую терминологию.

GZ>>МИФ. Существует миф, что для объектов Rich Domain Model обязательно наличие прозрачных reference между собой. Этот преступный миф не является правдой. Он не имеет отношения ни к Rich, ни к здравому смыслу. А имеет отношение к понятиям statefull, stateless и чисто опциональному lazy load. Единственное отличие, в Anemic – состояние разнесено с методами получения ссылочных объектов. В Rich – это единый объект.
IB>Либо ты сам себе противоречишь, либо я не понимаю о чем ты.
Ничего не противоречу. Между функцией получения, и ссылкой есть большая разница. И она сколько не физическая, а логическая.

GZ>>2. Инкапсуляция.
IB>Хочешь сказать, чот в Anemic ее нет или что в Rich она выше?
Я это уже сказал.

GZ>>Программисту, использующему данный объект, недоступно его состояние, кроме как определенный интерфейс.
IB>Проблема только в том, что в реальной жизни один фиг в бизнес объекте есть прямой доступ к данным, максимум обернутыми в свойства. В противном случае объект должен знать обо всех сценариях своего использования и меняться при появлении каждого нового сценария.
Ну возьмем к примеру ACL. ACL как данные, программисту не нужны, а иногда вредны. А вот средства проверки ACL для той или иной операции востребованы, и вполне могут жить в объекте.