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

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

MC>>Эм, ты щас про что?
IB>Про то что опысывая все это GlebZ, к сожалению много чего напутал и ясности не внес.

Ыыы, ну так напиши свое понимание этих моделей. Название новго треда "Anemic Domain Model vs Rich Domain Model (версия IB)", ну а мы почитаем. А еще интерсно было бы "Anemic Domain Model vs Rich Domain Model (версия gandjustas)". Сорри если я не правильно идентифицировал самых разговорчивых анемистов...

Реально по вашим размазаным по всему форуму постам непонятно что вы отстаиваете...

Да и мож не будут появляться фразы типа:
G>Я их не выдумываю. Их выдумывают приверженцы DDD. Напрмер aggregation root — огромный костыль DDD, который не я придумал. Также недавно тут пробегала ссылка на статью, которая рассказывала что reporting (практически любое отображение информации) надо делать не DDDшными средствами.
Могу и твоих фраз поискать про метод Сейв и тому подобное.

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

MC>Ыыы, ну так напиши свое понимание этих моделей.
Я уже давно написал.

MC>Реально по вашим размазаным по всему форуму постам непонятно что вы отстаиваете...
Какой вопрос интересует?

MC>Могу и твоих фраз поискать про метод Сейв и тому подобное.
Что тебе в моих постах не нравится?

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

MC>>Могу и твоих фраз поискать про метод Сейв и тому подобное.
IB>Что тебе в моих постах не нравится?

То же что и в постах gandjustas, сорри, но вы оба не шарите в рич моделях , .

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

GZ>Преимущества Anemic:
GZ>1. Простота построения. Это большой плюс, ибо главная задача архитектора, реализация функциональности за меньшие деньги. 90 процентов решений, могут быть построены в данной модели и это будет на порядок дешевле.
GZ>2. Бизнес-объекты – отчуждаемы. В результате, бизнес-объект может быть спокойно пронесен от DAL, к фасаду и даже далее. Беспрепятсвенно и идентично сериализован/десериализован между физическими слоями. В большинстве, бизнес-объект как бизнес-сущность не меняется при переносе между слоями.
GZ>3. Прогнозируемость и управляемость вплоть до DAL. Что под этим понимается. В случае, если вы ворочаете большими объемами данных, в Anemic вам проще управлять запросами к базе данных, чем в Rich. База данных была и остается самой тяжелой частью бизнес приложений. Оптимизация в основном достигается за счет повышения эффективности работы с базой данных(и зачастую не обычным редактирование SQL). В Anemic, вы спокойно можете провести тот, или иной сценарий через соседний сервис, который будет работать именно над этом тяжелым сценарием. В Rich — проблема как с прогнозом результирующего запроса, и с его оптимизацией.
GZ>4. Бизнес-объект проще управлять объектами, которые еще не полностью в валидированном состоянии. В Rich – наличие валидаторов обязывает держать валидированное состояние. Что иногда выливается в проблемы(например, когда объект только что создан, не имеет идентификатора, и не имеет тех, или иных ссылок). Во многом, бизнес-объект больше похож на данные, чем на объект в стиле объектного программирования.

Хотел бы подвергнуть сомнению все эти пункты:
1) Главная задача архитектора меняется в зависимости от типа проекта и даже его фазы. Могу по собственному опыту сказать, что зачастую она заключается в минимизации затрат на сопровождение и развитие. Хорошо приготовленная RDM в этом смысле превосходит ADM, и Вы перечислили причины почему в той части, где говорите о преимуществах RDM;
2) Переносимость бизнес-объектов между физическими звеньями (то есть за границы адресного пространства) -- довольно редкое требование, нет необходимости ориентироваться на него в общем случае. Использование бизнес-объектов RDM в разных слоях в пределах одного физического звена при адекватных инструментах никакой проблемы не составляет;
3) Если имеют место большие объёмы данных, то лучше вообще не связываться с Domain Model. К счастью, большинство транзакционных сценариев не предполагает большого количества объектов, а значит можно в полной мере использовать преимущества RDM;
4) Постоянная валидность бизнес-объектов и RDM -- совершенно не связанные между собой аспекты, в случае ADM точно так же можно наложить ограничение постоянной валидности. К тому же современные средства валидации бизнес-объектов поддерживают несколько степеней валидности, в зависимости от контекста.

GZ>Показания к использованию.
GZ>Во многом, IMHO, но…. Если вы ворочаете большими данными, то Anemic по любому. Если ваше приложение простое, то anemic. Если у вас большое количество сущностей, большее чем вы можете запомнить, и это не разбить на модули/компоненты/SOA, в которых будут бегать сотня программистов, то Rich. Но для Rich, нужно сразу запастись инструментальными средствами, типа Hibernate(у которого есть чудный кэш), и средства сериализации/десериализации. Это сгладит недостатки модели.

То, что Вы называете сглаживанием недостатков модели, я бы назвал просто правильным способом реализации RDM

P.S. Совсем недавно я писал развёрнутую статью на эту тему у себя в блоге, если любопытно:
http://javatoday.ru/2009/03/rich-domain-model/

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

GZ>>Могут появиться. А могут и не появиться. Зачем заниматься предварительной оптимизацией.
IB>Она не предварительная.

GZ>>Это не мера измерения.
IB>А что же это?
Инструмент.

GZ>>В основном измеряют цикломатическую сложность, coupling и cohesion.
IB>А не в основном?
До хрена всего, а самое главное, разными способами. Только это для отдельной темы.

GZ>>Ну, о чем и говорилось. И соответвенно, как минимум во все методы вызывающие данный метод.
IB>Это плохо? Еще раз — у тебя есть два варианта:
IB>1. Изменить бизнес-объект таким образом, чтобы вся необходимая информация уже была в нем в момент вызова.
+-1 Только тогда это будет аналог Rich. Только значительно хуже. Ибо в Rich, можно спрятать дополнительную информацию за интерфейсом и загружать по мере надобности, а для некоторых сценариев вообще загружать вместе с основным объектом, в Anemic — он неделим.

IB>2. Явно передать всю необходимую информацию при вызове.
+1 Но проблема, что это надо передавать каждый раз в разных сценариях. Таким образом, ты и связываешь разные места с контрактом ACLService.CanEdit. Увеличиваешь cohesion.

IB>И оба эти варианта лучше чем неявное поднятие нового объекта в CanEdit
Ну наконец-то. Начинаю тебя понимать. Смотрим что было изначально:

инкапсуляция выше, ресурсоемкость тоже

Со вторым ты вроде согласен. А вот первое, тебе покоя не дает. Несмотря на конкретный пример.

IB>Собственно, есть и третий вариант — ты можешь проинжектить ACLService, сервисом работы с данными и опять-таки поднять неявно родительский объект в CanEdit, но так делать не стоит — это мало чем будет отличаться от жирной модели, просто лишний раз подтверждает, что стройная легко покрывает описанный тобой сценарий.
Это как раз чрезвычайно сильно изменяет модель относительно Rich. Тады ACLService придется понимать с каким именно объектом он имеет дело.

GZ>>Почему? Если тебе для выполнения какого-то метода нужен только идентификатор, ты всегда отдаешь целый объект?
IB>Я не про отдачу, а про то что в момент отдачи у тебя полюбому целый объект.
Нет. Это может быть список объектов которые можно редактировать. А может быть и список идентификаторов объектов которые можно редактировать.

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

MC>Ыыы, ну так напиши свое понимание этих моделей. Название новго треда "Anemic Domain Model vs Rich Domain Model (версия IB)", ну а мы почитаем. А еще интерсно было бы "Anemic Domain Model vs Rich Domain Model (версия gandjustas)". Сорри если я не правильно идентифицировал самых разговорчивых анемистов...

MC>Реально по вашим размазаным по всему форуму постам непонятно что вы отстаиваете...

MC>Да и мож не будут появляться фразы типа:
G>>Я их не выдумываю. Их выдумывают приверженцы DDD. Напрмер aggregation root — огромный костыль DDD, который не я придумал. Также недавно тут пробегала ссылка на статью, которая рассказывала что reporting (практически любое отображение информации) надо делать не DDDшными средствами.
MC>Могу и твоих фраз поискать про метод Сейв и тому подобное.

Бгг, присоединяюсь )) Можно один топик с подтредом на каждого сильно разбирающегося в anemic и domain

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

MC>Ыыы, ну так напиши свое понимание этих моделей. Название новго треда "Anemic Domain Model vs Rich Domain Model (версия IB)", ну а мы почитаем. А еще интерсно было бы "Anemic Domain Model vs Rich Domain Model (версия gandjustas)". Сорри если я не правильно идентифицировал самых разговорчивых анемистов...

MC>Реально по вашим размазаным по всему форуму постам непонятно что вы отстаиваете...

MC>Да и мож не будут появляться фразы типа:
G>>Я их не выдумываю. Их выдумывают приверженцы DDD. Напрмер aggregation root — огромный костыль DDD, который не я придумал. Также недавно тут пробегала ссылка на статью, которая рассказывала что reporting (практически любое отображение информации) надо делать не DDDшными средствами.
MC>Могу и твоих фраз поискать про метод Сейв и тому подобное.

Сорри, как-то не так отправилось.

Бгг, присоединяюсь )) Можно один топик с подтредом на каждого сильно разбирающегося в anemic и domain

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

GZ>Инструмент.
Инструмент — это инкапсуляция, и есть метрика правильности его применения.

GZ>+-1 Только тогда это будет аналог Rich.
Нет. Самый близкий аналог Rich — это третий способ.

GZ>Только значительно хуже. Ибо в Rich, можно спрятать дополнительную информацию за интерфейсом и загружать по мере надобности.
Значительно лучше. Это не дополнительная информация, это всегда необходимая информация.
Никто не собирается грузить родителя сразу, необходимая информация уже есть в дочернем, он самодостаточен, ему ничего не нужно.
Причем эта информация не является лишней, она необходима при каждой проверке доступа (и наверняка не только доступа, раз доступ на нее завязан).

GZ>+1 Но проблема, что это надо передавать каждый раз в разных сценариях.
Это не проблема. Это как раз хорошо. Я явно в каждом сценарии понимаю, что нужно и явно это передаю.
Причем забыть и не передать, я не могу — компилятор поправит. И явно передавая — четко понимаешь чего это стоит в каждом сценарии и каждый сценарий, при необходимости, ты можешь настроить отдельно, не трогая другие (например, в одном случае получая нужный объект из кеша, а в другом напрямую в обход всего, если это критично — инкапсуляция в действии (с)).
Если же у тебя все сценарии одинаковые, то написать обобщенный код тоже не rocket science, так что и с трудоемкостью проблем нет.

GZ>Таким образом, ты и связываешь разные места с контрактом ACLService.CanEdit.
А раньше они типа не были связаны, что ли?

GZ>Увеличиваешь cohesion.
Так этож хорошо.. Но на самом деле с когезией здесь ничего не происходит.

GZ>Ну наконец-то. Начинаю тебя понимать.
Похоже нет.

GZ>Со вторым ты вроде согласен. А вот первое, тебе покоя не дает. Несмотря на конкретный пример.
Конкретный пример показывает ровно обратное твоему утверждению, особенно если под ресурсоемкостью понимать стоимость дальнейшей поддержки, а не количество нажатий на клавиши для единоразового изменения логики CanEdit.

GZ>Это как раз чрезвычайно сильно изменяет модель относительно Rich.
Нет, не меняет.

GZ>Тады ACLService придется понимать с каким именно объектом он имеет дело.
Ровно в той же степени, что и для Rich.

GZ>Нет. Это может быть список объектов которые можно редактировать. А может быть и список идентификаторов объектов которые можно редактировать.
Из базы все равно приезжает список объектов, а не идентификаторов.

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

MC>То же что и в постах gandjustas,
Что конкретно?

Здравствуйте, Лобанов Игорь, Вы писали:

ЛИ>Хорошо приготовленная RDM в этом смысле превосходит ADM,
В этом смысле с хорошо приготовленной стройной моделью вообще мало что сравнится.

ЛИ>2) Переносимость бизнес-объектов между физическими звеньями (то есть за границы адресного пространства) -- довольно редкое требование, нет необходимости ориентироваться на него в общем случае.
То есть, уже никто, ничего, никуда не сериализует?

ЛИ>Использование бизнес-объектов RDM в разных слоях в пределах одного физического звена при адекватных инструментах никакой проблемы не составляет;
Составляет и еще какую, вне зависимоти от инструментария. Когда обращение к одному полю в UI, совершенно "прозрачно" вызывает по цепочке серию обращений к БД для поднятия списка — это конкретная проблема.

ЛИ>3) а значит можно в полной мере использовать преимущества RDM;
Какие?

ЛИ>То, что Вы называете сглаживанием недостатков модели, я бы назвал просто правильным способом реализации RDM
То есть, Rich == ORM?

ЛИ>P.S. Совсем недавно я писал развёрнутую статью на эту тему у себя в блоге, если любопытно:
ЛИ>http://javatoday.ru/2009/03/rich-domain-model/

Прикладная логика, по определению, формулируется в терминах навигации по графу прикладных объектов и его изменении.

Это неверное определение, отсюда и неверные выводы в твоей статье..
А на кешировании, Lazy Loading-е и прочих продвинутых инструментах, облегчающих работу с жирной моделью — уже только ленивый не потоптался.

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

IB>Здравствуйте, Лобанов Игорь, Вы писали:

ЛИ>>2) Переносимость бизнес-объектов между физическими звеньями (то есть за границы адресного пространства) -- довольно редкое требование, нет необходимости ориентироваться на него в общем случае.
IB>То есть, уже никто, ничего, никуда не сериализует?
Я выдилил что именно никто и никуда не сериалзирует .


ЛИ>>Использование бизнес-объектов RDM в разных слоях в пределах одного физического звена при адекватных инструментах никакой проблемы не составляет;
IB>Составляет и еще какую, вне зависимоти от инструментария. Когда обращение к одному полю в UI, совершенно "прозрачно" вызывает по цепочке серию обращений к БД для поднятия списка — это конкретная проблема.

Ты сам отвечаеш на вопрос что именно мне не нравиться, вот например это не нравиться... Ну и откуда такие выводы? Сам придумал? У нас не бывает таких проблем.

Мы не биндим доменные обьекты прямо в УИ, все обращения контролируються... Так что у нас небывает непредвиденных сайдеффектов. Типа УИ чето решило поменять, а отвалилось в датаслое.

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

MC>Я выдилил что именно никто и никуда не сериалзирует .
То есть, бизнес-объекты никогда и никуда не сериализуются?

MC>Ты сам отвечаеш на вопрос что именно мне не нравиться, вот например это не нравиться...
Это вообще мало кому нравится, но это факт.

MC>Ну и откуда такие выводы? Сам придумал?
Нет, в жирной модели подсмотрел.

MC>Мы не биндим доменные обьекты прямо в УИ, все обращения контролируються...
Кем и как? То есть, мало того, что в бизнес-объектах логика, так еще и вокруг накрутили, чтобы контролировать то, с чем бизнес-объект не справляется?

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

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

MC>>Я выдилил что именно никто и никуда не сериалзирует .
IB>То есть, бизнес-объекты никогда и никуда не сериализуются?
У нас нет. Сериализация это такое же публичное АПИ. Для него есть контракты.

MC>>Ну и откуда такие выводы? Сам придумал?
IB>Нет, в жирной модели подсмотрел.
Смешно, ты подсматрел то чего нет. Тебе не кажеться что ситуация слегка глуповатая?

MC>>Мы не биндим доменные обьекты прямо в УИ, все обращения контролируються...
IB>Кем и как?
Програмистом. Код то не секретарка пишет.

IB>То есть, мало того, что в бизнес-объектах логика, так еще и вокруг накрутили,
Опять дето подглядел? Плаин ПОКО. Ни маркировочных атрибтов, ничего. Тока чистые методы и состояние — рай.

IB> чтобы контролировать то, с чем бизнес-объект не справляется?
А че бизнес обьект должен думать об УИ? Мы на него таких респонсибилитей вообще не вешаем.

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

IB>

IB>Прикладная логика, по определению, формулируется в терминах навигации по графу прикладных объектов и его изменении.

IB>Это неверное определение, отсюда и неверные выводы в твоей статье..

Во-первых, это не определение, а следствие из определения. Во-вторых, отсюда в статье не может быть неверных выводов, потому что это последний абзац статьи

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


S>Не обижайтесь, но у вас какое-то идеализированное представление о проектировании систем — берём требования, реализуем и все щасливы. Нифига!
Это действительно так. Достаточно накаждом этапе (сбор требований-анализ-проектирование-реализация) подключать мозг.

S>Во-первых требования никогда не содержат полной информации о предметной области. Это отдельная тема, подробнее стоит почитать у апологетов DDD.
И что? Разве кто-то мешает изучать предметную область?

S>Во-вторых, требования заказчика не всегда бывают выполнимыми: их нужно прноверять.
Лушче всего это делать на этапе анализа.

S>В-третьих если вам потребуется взаимодействие с внешними системами, от вас потребуется громадная куча фич, которые очевидны из предметной области, но не указаны в требованиях.
См выше.

S>В-четвёртых у модели предметной области приоритет банально выше: она стабильнее, требования заказчика гарантированно не могут выйти за пределы предметной области (точнее, могут захватить другую предметную область, но это другой разговор) и, самое главное, правила предметной области не зависят от хотелок заказчика/проектировщика и тем самым делает предсказуемым процесс разработки.
И что? Типа сначала надо модель предментной области забабахать, а потом думать как с ней программу написать.
Это дурацкий подход мягко говоря. В первую очередь на что надо ориентироваться — требования, предметная область вносит дополнительные ограничения не более того.

G>>Такие случаи требуют отдельного рассотрения так как размазывание логики между клиентом и сервером создает дополнительные проблмемы, которые не связаны с постановкой задачи.
G>>Я вообще склонен считать такие случаи паталогическими.
G>>Для поиска багов лучше тесты.

S>[ОФФТОП]
S>Про тесты: одно другого не отменяет. Лично мне куда проще саппортить такой код:
S>

S>void SomeMethod(string arg1, params int[] indexes)
S>{
S>  Code.NotNullOrEmpty(arg1, "arg1");
S>  Code.NotNull(indexes, "indexes");
S>  Code.GreaterThenOrEqual(indexes.Length, "indexes.Length", 5);
S>  Code.AssertState(CanDoSomeOperation, @"Some detailed exception message");

S>  // code goes here
S>}
S>

S>Сразу виден data contract + есть возможность отключать проверки по необходимости.
S>[/ОФФТОП]
Контракты — хорошо, только причем тут предметная область?

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

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

G>>Приверженцы DDD и зирной модели предлагают все засунуть в объекты и проверять чуть ли не при каждом изменении полей. Но такая реализация очень плохо работает, особенно для сложных правил, где требуется задействовать несколько объектов.
G>>Другой вариант делать все проверки при сохранении данных в БД, в таком случае проверка правил выноситстся в отдельные классы. Такой вариант предпочтительнее.
MC>Никто не мешает совмещать.
Я говореи не об удобстве, а о необходимости. Необходимы на самом деле только проверки при сохранении, для удобства можно хоть на каждый чих делать.
Хотя удобство тоже разное бывает. См ниже.

MC>Простейшие проверки можно сделать в сеттерах — тогда они будут срабатывать еще и прямо при редактировании в гриде или прибинденных полях редактирования — что по моему скромному мнению есть очень удобно.
Совсем неудобно. Как сделать client-side проверки в вебе при засовывании их в сеттеры?

MC>Более сложные проверки можно вынести либо в метод Validate либо в какой-то ValidationService().
Когда есть фреймворк валидации, то делать проверки в сеттерах бессмысленно (дублирование кода).

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

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

MC>>>Могу и твоих фраз поискать про метод Сейв и тому подобное.
IB>>Что тебе в моих постах не нравится?

MC>То же что и в постах gandjustas, сорри, но вы оба не шарите в рич моделях , .

О горе нам, как же мы с этим жить будем
Я еще на делфях создавал насколько возможно rich модель, затрахался сильно

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

MC>У нас нет. Сериализация это такое же публичное АПИ. Для него есть контракты.
То есть, все таки сериализуется. Или все-таки нет? Ты не виляй ты прямо скажи.

MC>Смешно, ты подсматрел то чего нет. Тебе не кажеться что ситуация слегка глуповатая?
Меня эта ситуация пока что забавляет. С одной стороны у тебя все зашибись и проблем ты в упор не видишь, а с другой ничего конкретного сказать не можешь, на прямые вопросы не отвечаешь.
Вывод, в принципе очевиден, но словоблудие забавное.. =)

MC>Програмистом. Код то не секретарка пишет.
Какой код пишет программист?

MC>Опять дето подглядел?
У тебя вычитал..

MC> Плаин ПОКО. Ни маркировочных атрибтов, ничего. Тока чистые методы и состояние — рай.
Так как ты свои ПОКО сериализуешь?

MC>А че бизнес обьект должен думать об УИ?
Бизнес-объект вообще думать не должен.

MC>Мы на него таких респонсибилитей вообще не вешаем.
А какие вешаете?

Здравствуйте, Лобанов Игорь, Вы писали:

ЛИ>Во-первых, это не определение, а следствие из определения.
Если определение не верное, то следствие уж тем более.

ЛИ>Во-вторых, отсюда в статье не может быть неверных выводов, потому что это последний абзац статьи
Какая разница, какой это абзац, если это и есть ключевой момент твоей критики, остальное просто вода вокруг..

Здравствуйте, Лобанов Игорь, Вы писали:

ЛИ>Хотел бы подвергнуть сомнению все эти пункты:
ЛИ>1) Главная задача архитектора меняется в зависимости от типа проекта и даже его фазы. Могу по собственному опыту сказать, что зачастую она заключается в минимизации затрат на сопровождение и развитие. Хорошо приготовленная RDM в этом смысле превосходит ADM, и Вы перечислили причины почему в той части, где говорите о преимуществах RDM;
Ну это просто неверно. Как ни крути, а rich нарушает SRP, что негативно сказывается на стоиомости сопровождения.


ЛИ>2) Переносимость бизнес-объектов между физическими звеньями (то есть за границы адресного пространства) -- довольно редкое требование, нет необходимости ориентироваться на него в общем случае.

Я бы архитектора выгнал сразу за такие слова.
Основа снижения издержек на развитие ПО — обеспечить повторное использование дизайнерксих решений. Говоря по русски — надо чтобы код не менялся даже если понадобится превратить двузвенное десктоп решение в веб.

ЛИ>Использование бизнес-объектов RDM в разных слоях в пределах одного физического звена при адекватных инструментах никакой проблемы не составляет;
Ну жирные объекты с LL так просто не протащишь. Сложная логика также станет недоступна на клиенте, а методы из объектов никуда не денутся.

ЛИ>3) Если имеют место большие объёмы данных, то лучше вообще не связываться с Domain Model. К счастью, большинство транзакционных сценариев не предполагает большого количества объектов, а значит можно в полной мере использовать преимущества RDM;
Еще раз? Какие премущества rich перед anemic? Бредятину типа "в ней больше ООП" не рассматриваем.
Покажите пример кода, где по rich гораздо удобнее anemic.