Что-то слишком уж разнятся понимания что же такое Толстая архитектура, а что такое стройная архитектура. Слишком много терминов и разночтений. Попробую пояснить оба этих понятия.
Rich Domain Model, в простонародье, толстая модель, концепция построения логической архитектуры, в которых бизнес-объекты содержат бизнес-логику. Или можно наоборот, бизнес-логика содержит состояние бизнес-объектов.
Anemic Domain Model – почему-то некоторые называют стройной моделью, но особо и не слышал о нормальном(адекватном) русском переводе данного термина. Лично я обычно называю нетолстой моделью. Так понятней. Итак, Anemic Domain Model – концепция построение логической архитектуры, в которой состояние бизнес-объектов разнесено с объектами бизнес-логики обрабатывающих их.
Эти два термина в английском варианте я и буду использовать в дальнейшем, во избежание разночтений.
ФАУЛЕР. Фаулер дал другую терминологию: Transaction Sript и Domain Model. Под Domain Model некоторые понимают Rich Domain Model, что не является правдой, под Transaction Script – Anemic Domain Model. Но если с первым термином не очень логично, второй термин сразу ушел в небытие, и обществом принят не был.
МИФ. Существует миф, что для объектов Rich Domain Model обязательно наличие прозрачных reference между собой. Этот преступный миф не является правдой. Он не имеет отношения ни к Rich, ни к здравому смыслу. А имеет отношение к понятиям statefull, stateless и чисто опциональному lazy load. Единственное отличие, в Anemic – состояние разнесено с методами получения ссылочных объектов. В Rich – это единый объект.
В Anemic:
Это немного, однако оно приводит к значительном различии в архитектуре. И та, и другая модель имеет те, или иные достоинства, и недостатки:
Преимущества Anemic:
1. Простота построения. Это большой плюс, ибо главная задача архитектора, реализация функциональности за меньшие деньги. 90 процентов решений, могут быть построены в данной модели и это будет на порядок дешевле.
2. Бизнес-объекты – отчуждаемы. В результате, бизнес-объект может быть спокойно пронесен от DAL, к фасаду и даже далее. Беспрепятсвенно и идентично сериализован/десериализован между физическими слоями. В большинстве, бизнес-объект как бизнес-сущность не меняется при переносе между слоями.
3. Прогнозируемость и управляемость вплоть до DAL. Что под этим понимается. В случае, если вы ворочаете большими объемами данных, в Anemic вам проще управлять запросами к базе данных, чем в Rich. База данных была и остается самой тяжелой частью бизнес приложений. Оптимизация в основном достигается за счет повышения эффективности работы с базой данных(и зачастую не обычным редактирование SQL). В Anemic, вы спокойно можете провести тот, или иной сценарий через соседний сервис, который будет работать именно над этом тяжелым сценарием. В Rich — проблема как с прогнозом результирующего запроса, и с его оптимизацией.
4. Бизнес-объект проще управлять объектами, которые еще не полностью в валидированном состоянии. В Rich – наличие валидаторов обязывает держать валидированное состояние. Что иногда выливается в проблемы(например, когда объект только что создан, не имеет идентификатора, и не имеет тех, или иных ссылок). Во многом, бизнес-объект больше похож на данные, чем на объект в стиле объектного программирования.
Преимущества Rich:
1. Простота использования. Объекты всегда под рукой. Средства обработки объектов, также под рукой. Использовать Rich – значительно проще, особенно когда в проекте новичок.
2. Инкапсуляция. Программисту, использующему данный объект, недоступно его состояние, кроме как определенный интерфейс. Это локализует некоторые изменения в логике. Но тут следует упомянуть, что те изменения, которые касаются состояния, также отслеживаются компиляцией со статической типизацией в Anemic, что покрывает большее количество таких проблем.
3. Меньшее количество мусора. В Anemic приходится отслеживать, чтобы в ворохе сервисов не делали свои велосипеды. В Rich c этим меньше проблем в силу более сильной локализации логики.
Действительность.
Чисто Anemic, а тем более Rich в абсолютно чистом виде не бывает. Бизнес-объект как минимум содержит типизацию, что является частью бизнес-логики, в Rich – по любому приходится делать более высокоуровневые сервисы.
Показания к использованию.
Во многом, IMHO, но…. Если вы ворочаете большими данными, то Anemic по любому. Если ваше приложение простое, то anemic. Если у вас большое количество сущностей, большее чем вы можете запомнить, и это не разбить на модули/компоненты/SOA, в которых будут бегать сотня программистов, то Rich. Но для Rich, нужно сразу запастись инструментальными средствами, типа Hibernate(у которого есть чудный кэш), и средства сериализации/десериализации. Это сгладит недостатки модели.
О себе.
Долгое стародавнее время писал в стиле Rich(вынужден сказать, что не по поводу). Последнее время(а это n лет) пишу только в Anemic.
Теперича можно обсуждать, осуждать, предлагать пойти в лесок с топором погуляти и etc
Здравствуйте, GlebZ, Вы писали:
GZ>ФАУЛЕР. Фаулер дал другую терминологию: Transaction Sript и Domain Model.
Автор терминов Rich Domain Model и Anemic Domain Model — Фаулер.
Кратко говоря — Фаулер разбирая Domain Model говорит, что Rich — это правильная Domain Model, а Anemic — не правильная. Таким образом, к Transaction Sript это не имеет никакого отношения, если говорить о Фаулеровских терминах.
Так что прежде чем писать про Anemic vs Rich, не плохобы написать, что такое вообще Domain Model, чего я добивался еще в прошлый раз.
GZ>Под Domain Model некоторые понимают Rich Domain Model, что не является правдой,
Это ты Фаулеру скажи..
GZ>МИФ. Существует миф, что для объектов Rich Domain Model обязательно наличие прозрачных reference между собой. Этот преступный миф не является правдой. Он не имеет отношения ни к Rich, ни к здравому смыслу. А имеет отношение к понятиям statefull, stateless и чисто опциональному lazy load. Единственное отличие, в Anemic – состояние разнесено с методами получения ссылочных объектов. В Rich – это единый объект.
Либо ты сам себе противоречишь, либо я не понимаю о чем ты.
GZ>2. Инкапсуляция.
Хочешь сказать, чот в Anemic ее нет или что в Rich она выше?
GZ>Программисту, использующему данный объект, недоступно его состояние, кроме как определенный интерфейс.
Проблема только в том, что в реальной жизни один фиг в бизнес объекте есть прямой доступ к данным, максимум обернутыми в свойства. В противном случае объект должен знать обо всех сценариях своего использования и меняться при появлении каждого нового сценария.
Здравствуйте, 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 для той или иной операции востребованы, и вполне могут жить в объекте.
Здравствуйте, GlebZ, Вы писали:
GZ>Что такое модель предметной области? Она есть всегда и везде. Ибо по ней и создается архитектура.
Эта "модель предметной области" всегда напрямую выражается в коде?
GZ>Ничего не противоречу. Между функцией получения, и ссылкой есть большая разница. И она сколько не физическая, а логическая.
Хрен редьки не слаще.
IB>>Хочешь сказать, чот в Anemic ее нет или что в Rich она выше? GZ>Я это уже сказал.
Ну и зря, инкапсуляция в стройной модели ничуть не ниже, а как правило и выше.
GZ>Ну возьмем к примеру ACL. ACL как данные, программисту не нужны, а иногда вредны. А вот средства проверки ACL для той или иной операции востребованы, и вполне могут жить в объекте.
так прикладному программисту они действительно не нужны, а тому, который всю логику вокург ACL реализует, очень даже пригодятся.
GZ>Преимущества Rich: GZ>2. Инкапсуляция. Программисту, использующему данный объект, недоступно его состояние, кроме как определенный интерфейс. Это локализует некоторые изменения в логике.
Недоступно состояние? а как пользователю на экране это недступное состояние показать?
А если есть функционал, затрагивающий несколько объектов?
Здравствуйте, IB, Вы писали:
IB>Эта "модель предметной области" всегда напрямую выражается в коде?
Зависит от архитектора. Модель предметной области — термин постановки а не архитектуры. В лучшем случае, набор документации написанной постановщиком, в худшем — абстрактная модель в голове программиста.
IB>Хрен редьки не слаще.
Вопрос инстанцирования? Я вполне нормально описал в чем разница, и что не надо путать.
IB>>>Хочешь сказать, чот в Anemic ее нет или что в Rich она выше? GZ>>Я это уже сказал. IB>Ну и зря, инкапсуляция в стройной модели ничуть не ниже, а как правило и выше.
Если ты об этом? здесь
То это был неправильный твой перевод. Говорилось о вреде излишней инкапсуляции(в чем я абсолютно согласен ибо уменьшают cohesion), а не о том что она выше. По крайней мере — это смешно... Открытые данные более инкапсулированы чем приватные.
GZ>>Ну возьмем к примеру ACL. ACL как данные, программисту не нужны, а иногда вредны. А вот средства проверки ACL для той или иной операции востребованы, и вполне могут жить в объекте. IB>так прикладному программисту они действительно не нужны, а тому, который всю логику вокург ACL реализует, очень даже пригодятся.
Об этом и разговор. У прикладника нет возможности влезть в логику куда ему лезть не стоит.
Здравствуйте, gandjustas, Вы писали:
GZ>>2. Инкапсуляция. Программисту, использующему данный объект, недоступно его состояние, кроме как определенный интерфейс. Это локализует некоторые изменения в логике. G>Недоступно состояние? а как пользователю на экране это недступное состояние показать? G>Кстати, инкаписуляция != data hiding.
Блин.... Ёкарный бабай. Ну ты тыкни где я писал что инкапсуляция = data hiding. Найди выдели и тыкни пальцем и выругайся. Мы понимать что написано умеем? Мне нужно описывать все терминалогию, от инкапсуляции до понятия байта?
G>А если есть функционал, затрагивающий несколько объектов?
А ты всегда и все показываешь? Списки доступа, гуиды, средства построения деревьев при адресации по идентификаторам?
Неправильно откопировал G>>Недоступно состояние? а как пользователю на экране это недступное состояние показать? GZ>А ты всегда и все показываешь? Списки доступа, гуиды, средства построения деревьев при адресации по идентификаторам?
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, gandjustas, Вы писали:
GZ>>>2. Инкапсуляция. Программисту, использующему данный объект, недоступно его состояние, кроме как определенный интерфейс. Это локализует некоторые изменения в логике. G>>Недоступно состояние? а как пользователю на экране это недступное состояние показать? G>>Кстати, инкаписуляция != data hiding. GZ>Блин.... Ёкарный бабай. Ну ты тыкни где я писал что инкапсуляция = data hiding. Найди выдели и тыкни пальцем и выругайся.
Выделил. Если надо показывать на экране, то это data hiding.
G>>А если есть функционал, затрагивающий несколько объектов? GZ>А ты всегда и все показываешь? Списки доступа, гуиды,
нет, я их даже не считываю.
GZ>средства построения деревьев при адресации по идентификаторам?
такое тоже в базе хранится?
Здравствуйте, GlebZ, Вы писали:
GZ>Что-то слишком уж разнятся понимания что же такое Толстая архитектура, а что такое стройная архитектура. Слишком много терминов и разночтений. Попробую пояснить оба этих понятия.
[..]
GZ>Показания к использованию. GZ>Во многом, IMHO, но…. Если вы ворочаете большими данными, то Anemic по любому. Если ваше приложение простое, то anemic. Если у вас большое количество сущностей, большее чем вы можете запомнить, и это не разбить на модули/компоненты/SOA, в которых будут бегать сотня программистов, то Rich. Но для Rich, нужно сразу запастись инструментальными средствами, типа Hibernate(у которого есть чудный кэш), и средства сериализации/десериализации.
Это сгладит недостатки модели.
Можно вставить свои пять копеек по поводу использования? Вы говорите о том, что нужно выбрать; наверное, правильнее будет говорить о том, в какую сторону делать уклон, потому что в чистом виде все равно не получится.
Ну и вдобавок что хотел сказать по поводу критериев выбора -- есть еще понятие data-centric и object-centric model. Если вы придерживаетесь первого (data-centric), то стоит двигаться в сторону anemic. Если object-centric -- то к RichModel. Потому как на примере своего приложения -- несмотря на то, что очень много сущностей, но за счет их data-centric природы anemic model неплохо удовлетворяет нужды.
И еще -- если есть колебания, что выбрать, можно грубо можно пользоваться простой аналогией: Rich Model <--> Active Record. Если AR устраивает, можно выбирать rich model, если же выглядит неприемлемой -- стоит грести к anemic.
Здравствуйте, gandjustas, Вы писали:
GZ>Программисту, использующему данный объект, недоступно его состояние, кроме как через определенный интерфейс.
Объясняю. Только не выделенное, а всю фразу. Чтобы параноидально по полочкам.
Инкапсуляция — средство локализации функционала в сухом и потребном месте. Для локализации функционала, нужно иметь некоторый интерфейс(в фразе это слово присутсвует). Все что за этим интерфейсом, как бы то ни было, данные, функции, объекты, мамонты и мамонтихи, скрываются. Таким образом, я нигде не писал что data hiding=incapsulation. Но то что data hiding может являться средством инкапсуляции, и в большинстве случаев для людей с головой является таковым, я как то даже стесняюсь говорить.
Здравствуйте, GlebZ, Вы писали:
GZ>Зависит от архитектора. GZ>Модель предметной области — термин постановки а не архитектуры. В лучшем случае, набор документации написанной постановщиком, в худшем — абстрактная модель в голове программиста.
Отлично, так в какой момент это все переходит в Domain Model в терминах Фаулера? он-то говорит именно об архитектурном решении.
GZ>Вопрос инстанцирования? Я вполне нормально описал в чем разница, и что не надо путать.
Вопрос использования.
IB>То это был неправильный твой перевод.
Правильный.
IB>Говорилось о вреде излишней инкапсуляции(в чем я абсолютно согласен ибо уменьшают cohesion), а не о том что она выше.
Именно о том, что она выше.
IB> По крайней мере — это смешно... Открытые данные более инкапсулированы чем приватные.
В том-то и дело, что не будут они у тебя приватными, в реальной жизни. Иначе получается как раз та самая "излишняя инкапсуляция"
GZ>Об этом и разговор. У прикладника нет возможности влезть в логику куда ему лезть не стоит.
Не об этом, а о том, что у того, кто разрабатывает логику работы вокруг ACL все равно придется делать это отдельной сущностью, так как всю эту логику в отдельный класс не запихнешь уж очень она развесистая.
МИФЫ ходящие по rsdn.
МИФ №2
Вся логика находися в бизнес-объекта. Господа и товарищи... Никто из приверженцев Rich модели из ума не выжил. Сложные сценарии не инкапсулируются в самих бизнес-объектах.
Миф №3
У толстой модели нет единой точки входа. Точка входа всегда есть. Называется фасад. Для него больше придется положить усилий и трудов, но он есть. И в нем, можно создавать контексты транзакций, аутентификацию, и проводить сериализацию.
Здравствуйте, IB, Вы писали:
IB>Отлично, так в какой момент это все переходит в Domain Model в терминах Фаулера? он-то говорит именно об архитектурном решении.
Ладно, поехали снова. Мне кажется мы больше издеваемся друг над другом, чем ищем вселенское благо. Давай забудем об архитектуре как таковой, а займемся буквоедством, то бишь паттернами.
Берем сайт Фаулера:
Для Domain Model:
An object model of the domain that incorporates both behavior and data.
Для Transaction Script:
Organizes business logic by procedures where each procedure handles a single request from the presentation.
Надо отдать ему должное, в его вышеупомянутой книжке описывается то же самое.
Первое что бросается в глаза для Domain Model — both behavior and data. Чудненько и прекрасно. Очень похоже на Rich, если бы не абстрактный object model под которым можно понимать все что угодно.
Второе — Transaction Script. И совершенно ничего не говорится о том, что сами параметры процедур, точно также могут описывать предметную область. И тут начинается буза. С одной стороны, если мы используем бизнес объекты в Transaction Script, то чем это не object model? Можно спокойно построить логическую диаграмму объектов. То есть это же получится Domain Model? Фаулер вышел из этой загвоздки, разделением понятия Domain Model на паттерн и антипаттерн. Ну что же делать, дикари-с. Впрочем он никогда и не скрывал, что Anemic — это смесь Domain Model и Transaciton Script.
GZ>>Вопрос инстанцирования? Я вполне нормально описал в чем разница, и что не надо путать. IB>Вопрос использования.
Перечитай весь параграф. Я говорил именно об инстанцировании.
IB>> По крайней мере — это смешно... Открытые данные более инкапсулированы чем приватные. IB>В том-то и дело, что не будут они у тебя приватными, в реальной жизни.
Смотря для кого? DAL — это также инкапсуляция работы с БД. Мы не говорим что оно инкапсулировано от самих объектов DAL. Но оно инкапсулировано относитель BLL, и изолировано от слоя еще выше. IB>Иначе получается как раз та самая "излишняя инкапсуляция"
Инкапсуляция не может быть измерена. В отличие от Low Cohesion, High Coupling.
GZ>>Об этом и разговор. У прикладника нет возможности влезть в логику куда ему лезть не стоит. IB>Не об этом, а о том, что у того, кто разрабатывает логику работы вокруг ACL все равно придется делать это отдельной сущностью, так как всю эту логику в отдельный класс не запихнешь уж очень она развесистая.
Абсолютно верно. Но тут как раз два подхода. Для одного подхода — это сервис. Для второго подхода, это вопрос иерархии наследования.
Кстати, это действительно интересный пример разницы:
Например, в случае anemic:
bool ACLService.CanEdit(Guid id, Guid idUser);
в случае Rich:
bool MyEditableObject.CanEdit(Guid idUser);
Вызовы похожи, а вот реализация совершенно разная.
В первом случае, мы имеем сервис в котором мы можем получить подсчитать список доступа для данного объекта, например какие пользователи могут пользоваться этим объектом и закэшировать эту инфу в самом сервисе. Нам не нужен сам объект по сути. Мы вполне можем его не загружать когда он не требуется.
Во втором случае, мы можем в Lazy Load точно также рассчитать реальный ACL через определенный сервис, и хранить его в самом объекте, закэшировав сам объект. Второе в данном случае менее эффективно потому как приходится загружать объект, но несколько более эффектиный кэш. Пока не изменен список доступа определенного пользователя все более менее, но если он поменялся. В результате, в ACLService мы вполне достойно можем почистить кэш контролируемый нами. А в случае с бизнес объектом, нам придется высчитывать кто есть лишний на этом празднике жизни, и как ему об этом сообщить. Задача вполне решаемая, но все таки обладающая некоторой трудоемкостью.
Далее, тут у нас начинается коренная доработка, в которой говорится что доступ к MyEditableObject складывается от ACL не только самого объекта, но еще и его непосредственного parent. И тут начинаются траблы. Использовать ACLService.CanEdit мы никаким боком использовать не можем, поскольку для выдачи решения нам не хватает информации. Injection тут не поможет по той же причине, и нам приходится героически переделывать вызовы сервиса там, где информация о том что это именно MyEditableObject присутсвует. В случае Rich — нам достаточно переделать реализацию CanEdit, ну например, на вызов return ACLService.CanEdit(id, parentId, userId) или вообще сделать ACLEditableObjService. Инкапсуляция в действии.
Так что лезвие бритвы — инкапсуляция выше, ресурсоемкость тоже.
Здравствуйте, GlebZ, Вы писали:
GZ>Organizes business logic by procedures where each procedure handles a single request from the presentation.
Какое-то странное определение, ограничивающие Transaction Script презентацией, типа логики не может быть вообще.
GZ>Первое что бросается в глаза для Domain Model — both behavior and data. Чудненько и прекрасно. Очень похоже на Rich, если бы не абстрактный object model под которым можно понимать все что угодно.
Это ты уже спекуляциями начинаешь заниматься — гаданием по Фаулеру, что же он имел ввиду.
GZ> Впрочем он никогда и не скрывал, что Anemic — это смесь Domain Model и Transaciton Script.
Единственное что он говорил по этому поводу — "Какой кошмар, это же почти Transaction Script, это не ООП, а процедурное программирование" (С)
GZ>Я говорил именно об инстанцировании.
А я об использовании.
GZ>Смотря для кого?
Для всего. У свойства дающего прямой доступ к данным стоит модификатор public.
GZ>Но оно инкапсулировано относитель BLL, и изолировано от слоя еще выше.
Каким боком?
GZ>Инкапсуляция не может быть измерена.
Инкапсуляция отлично меряется, что подробно расписано у того же Меерса.
GZ>Использовать ACLService.CanEdit мы никаким боком использовать не можем, поскольку для выдачи решения нам не хватает информации.
Мы можем прекрасным образом использовать ACLService.CanEdit передав ему всю необходимую информацию — либо самого parent-а, либо построив бизнес объект таким образом, чтобы вся необходимая информация уже была в нем.
Разница лишь в том, что в отличии от Rich ты сделаешь это явно, причем именно там где полагается — при обращении к ACL, а в случае Rich, спустя какое-то время ты будешь сильно удивляться — какого хрена при обращении к MyObj.CanEdit он еще и к родителю лезет.
GZ> В случае Rich — нам достаточно переделать реализацию CanEdit,
В стройной модели тоже самое.
GZ> Инкапсуляция в действии.
Во-во, излишняя инкапсуляция в действии.
GZ>Так что лезвие бритвы — инкапсуляция выше, ресурсоемкость тоже.
Я думаю — ты уже понял, где ошибался? =)
Надо разделять БЛ и логику предметной области (намеренно не использую слово Domain, т.к. его все по разному понимают).
Что такое предметная область? Это грубо говоря поле игры заказчика, то что никак не зависит от его желаний/способа организации бизнеса.
Например независимо от желания аэроперевозчика у самолётов конечная вместимость. Ограничение на нерастяжимость самолёта — часть предметной области и по-хорошему должно проверяться силами самой model (в идеале при попытке изменения в дополнение к проверке при сохранении изменений).
И так набирается куча логики, которая к самой БЛ никакого отношения не имеет. Разгрузка БЛ позволяет нехило упростить саппорт и изменение — т.к. БЛ выглядит как последовательность операций над предметной областью, элементарно расписывается и проверяется даже неспециалистами в программировании.
Ещё одно достоинство — перекрёстная проверка. Если вас какое-то требование не укладывается в модель, то либо заказчик гонит пургу, либо у вас кривая модель предметной области.
Об этом Эванс неплохо писал в "Domain-driven-design: tackling the complexity in the heart of software". Правда во второй части он зачем-то опровергает сам себя и смешивает БЛ и domain model обратно
Проблему надо просто решать на уровне архитектуры приложения а не ждать пока она вылезет в кривом дизайне DAL/контроллера. Тогда и не будет споров "anemic vs rich" и "mvc or not mvc".
Здравствуйте, meowth, Вы писали:
M>И еще -- если есть колебания, что выбрать, можно грубо можно пользоваться простой аналогией: Rich Model <--> Active Record. Если AR устраивает, можно выбирать rich model, если же выглядит неприемлемой -- стоит грести к anemic.
Здравствуйте, IB:
IB>Единственное что он говорил по этому поводу — "Какой кошмар, это же почти Transaction Script, это не ООП, а процедурное программирование" (С)
Если я нигде ничего не вру, там шла речь в контексте реализации UoW, да ещё и бизнес-процессы упоминались (мы говорим о его книжке "enterprise что-тотам"?).
А ООП как ни странно немногое здесь может предложить, т.к. задача ближе к реализации workflow модели. Я говорю не реализации отдельных кирпичиков, а именно об управлении процессами. И тут проблема о двух концах — либо у нас мегауниверсальные кирпичики, и трёхтомное "введение в конфигурацию для начинающих", либо кирпичики пишутся под задачи, но тогда уж не обижайтесь на "процедурное программирование".
Кстати, не втыкали в большинство описаний "типовых моделей бизнес процессов"? Там в основном идёт речь именно о воркфлоу как поэтапном изменении состояния. И процессы и ресурсы явно ставятся ортогонально друг другу. Так что это чуть ли не специфика бизнес-логики выходит.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, GlebZ, Вы писали:
S>А знаете в чём здесь загвоздка?
S>Надо разделять БЛ и логику предметной области (намеренно не использую слово Domain, т.к. его все по разному понимают). S>Что такое предметная область? Это грубо говоря поле игры заказчика, то что никак не зависит от его желаний/способа организации бизнеса.
Наведите порядок в терминологии. Есть части BL — business-rules — правила валидации модели и business-transactions — операции переводящие модель из одного состояния в другое.
В подавляющем большинстве случаев business-transactions сводятся к транзакциям БД. В более сложных случаях имеет смысл умышленно сводить бизнес-транзакции к системным транзакциям.
S>Например независимо от желания аэроперевозчика у самолётов конечная вместимость. Ограничение на нерастяжимость самолёта — часть предметной области и по-хорошему должно проверяться силами самой model (в идеале при попытке изменения в дополнение к проверке при сохранении изменений).
А вот тут возникает самый нтересный вопрос: когда проверять business-rules.
Приверженцы DDD и зирной модели предлагают все засунуть в объекты и проверять чуть ли не при каждом изменении полей. Но такая реализация очень плохо работает, особенно для сложных правил, где требуется задействовать несколько объектов.
Другой вариант делать все проверки при сохранении данных в БД, в таком случае проверка правил выноситстся в отдельные классы. Такой вариант предпочтительнее.
Но если еще на этапе анализа включить мозг, то окажется что многие business-rules являются предусловиями к некоторым операциям. Например самолет: хоть у него и конечная вместимость, но это имеет смысл только при операции погрузки.
ЗЫ. Я еще не упоминул про busines-operations, которые состоят из множества business-transactions, возможо растянутых по времени.
Здравствуйте, gandjustas, Вы писали:
G>Приверженцы DDD и зирной модели предлагают все засунуть в объекты и проверять чуть ли не при каждом изменении полей.
Можно ссылку на выделенное?
G> Но такая реализация очень плохо работает, особенно для сложных правил, где требуется задействовать несколько объектов. G>Другой вариант делать все проверки при сохранении данных в БД, в таком случае проверка правил выноситстся в отдельные классы. Такой вариант предпочтительнее.
Мне кажется ты приписываешь DDD выдуманные недостатки, а потом их сокрушительно критикуешь.
Мы уже победили, просто это еще не так заметно...
