Здравствуйте, Mike Chaliy, Вы писали:
MC>Здравствуйте, gandjustas, Вы писали:
MC>>>И что? Это проблема? G>>Вообще то да. G>>Чтобы сформировать ProductListItem (три поля) тебе понадобится поднять в память весь product, весь список связанных Image, а только потом маппер сделает 3 поля. MC>Если это станет проблемой, а оно не станет, как я говорил у нас кеши. Мы прикрутим кастомный репорт.
Уууу.... для такой простой операции еще и кеши... Ну вообще дец.
Все на надо больше доказывать что rich — говно. Я это и так знаю.
G>>Это просто нету сложных выборок. Например как получить список заказов с суммой , если сумма не кешируется в самом заказе? MC>Незнаю, ты придумал себе проблему ты и решай. У нас суммы не кешируються. У нас они сохраняються.
А небо не голубое, а светлосинее?
Я такую проблему спокойно решаю, по несколько раз в день. Просто пишу Linq запрос.
А вот как ты эту проблему решишь с таким подходом даже интересно.
ЛИ>>2) Переносимость бизнес-объектов между физическими звеньями (то есть за границы адресного пространства) -- довольно редкое требование, нет необходимости ориентироваться на него в общем случае. G> G>Я бы архитектора выгнал сразу за такие слова. G>Основа снижения издержек на развитие ПО — обеспечить повторное использование дизайнерксих решений. Говоря по русски — надо чтобы код не менялся даже если понадобится превратить двузвенное десктоп решение в веб.
Подозреваю, что буду десятым человеком, прицепившимся к этой фразе, но во-первых: к объектам на разных слоях могут применяться разные требования, и разработка универсального дизайнерского решения для покрытия двух наборов требований может вылиться в конце-концов в датасеты, и увеличение издержек. Во-вторых, какой именно код не должен меняться? Код представления, очевидно, не то что поменяется — перепишется заново. Код модели — поменяется вряд-ли, если только он не был разработан с оглядкой на UI.
ЛИ>>Использование бизнес-объектов RDM в разных слоях в пределах одного физического звена при адекватных инструментах никакой проблемы не составляет; G>Ну жирные объекты с LL так просто не протащишь. Сложная логика также станет недоступна на клиенте, а методы из объектов никуда не денутся.
Проблему составляет не отложенная загрузка как таковая (хотя если используется проксирование, то прокси нужно научить правильно сериализировать себя), а большая иерархичность модели.
ЛИ>>3) Если имеют место большие объёмы данных, то лучше вообще не связываться с Domain Model. К счастью, большинство транзакционных сценариев не предполагает большого количества объектов, а значит можно в полной мере использовать преимущества RDM; G>Еще раз? Какие премущества rich перед anemic? Бредятину типа "в ней больше ООП" не рассматриваем. G>Покажите пример кода, где по rich гораздо удобнее anemic.
Сорри, что отвечаю не вам, а человеку, которому отвечали вы. Как раз большие объемы данных — это хороший повод использовать объекты, потому как в .NET-е, по крайней мере, надо пользоваться или датаридером, или, если это невозможно, то восстанавливать объекты. Потому что если задача требует хранить данные в памяти (подчеркиваю жирным и красным ), то объекты и массивы — это наиболее удобный, экономный и естественный способ представления данных. Любые контейнеры данных будут заведомо более избыточны, чем объекты. Конечно, возможна экзотика, когда такой подход неприменим: например, резалтсеты разной структуры. И конечно же, само собой, то, что можно делать в базе, надо делать в базе.
Здравствуйте, Mike Chaliy, Вы писали:
MC>Здравствуйте, gandjustas, Вы писали:
G>>Юзкейс из моего проекта. Только админ может видеть\редактировать\еще_что_то_делать с сущностями X, которые невидимы (Visible = false). G>>Короче для каждой операции надо накладывать условие выборки. У меня всо всех случаях (хоть репортиг, хоть что-то еще) делает это один и тот же код. G>>(На самом деле это делается для всех сущностей, у которых есть видимость, одним и тем же кодом)
G>>В твоем случае придется два раза писать для reporting и domain.
MC>Я не вижу дублирования.
MC>1) Первое у нас в продукте есть Multitenancy. Это когда в одной БД можут находиться несколько разных приложений (это мы економим на хосете моде). Реализвано приблизительно как в http://java.dzone.com/articles/introduction-hibernate-filters У нас аналогичное тока програмно. Мы не используем ХМЛ. MC>Фактически с фильтром приложение не видит ничего из того что ей не позволено.
MC>2) Ну а второе, секурити тримминг это не респонсибилити модели. Этим может заниматься тока ендинтерфейс, ну или аппликейшен фасады. В домене вообще нема понятия Админа.
Ну и как такое требование реализуется поверх domain model во всех кейсах?
Неважно что там будет между UI и моделью.
Кстати это по твоей классификации логикой является?
Здравствуйте, Sergey T., Вы писали:
ST>Здравствуйте, gandjustas, Вы писали:
ЛИ>>>2) Переносимость бизнес-объектов между физическими звеньями (то есть за границы адресного пространства) -- довольно редкое требование, нет необходимости ориентироваться на него в общем случае. G>> G>>Я бы архитектора выгнал сразу за такие слова. G>>Основа снижения издержек на развитие ПО — обеспечить повторное использование дизайнерксих решений. Говоря по русски — надо чтобы код не менялся даже если понадобится превратить двузвенное десктоп решение в веб.
ST>Подозреваю, что буду десятым человеком, прицепившимся к этой фразе, но во-первых: к объектам на разных слоях могут применяться разные требования, и разработка универсального дизайнерского решения для покрытия двух наборов требований может вылиться в конце-концов в датасеты, и увеличение издержек.
Не надо проектировать в терминах объектов. Проектировать надо в терминах функций.
ST>Во-вторых, какой именно код не должен меняться? Код представления, очевидно, не то что поменяется — перепишется заново. Код модели — поменяется вряд-ли, если только он не был разработан с оглядкой на UI.
Да, такова теория. Она разбивается о жестокую реальность stateless веба и запросоориентированности.
Надо быть по-настоящему крутым архитектором чтобы обеспечить возможность такого перехода безболезненно.
ЛИ>>>Использование бизнес-объектов RDM в разных слоях в пределах одного физического звена при адекватных инструментах никакой проблемы не составляет; G>>Ну жирные объекты с LL так просто не протащишь. Сложная логика также станет недоступна на клиенте, а методы из объектов никуда не денутся. ST>Проблему составляет не отложенная загрузка как таковая (хотя если используется проксирование, то прокси нужно научить правильно сериализировать себя), а большая иерархичность модели.
Мне иерархичность модели никогда не мешала (в SQL то она не мешает). Мешают именно средства работы с этой иерархией.
Здравствуйте, gandjustas, Вы писали:
G>Не надо проектировать в терминах объектов. Проектировать надо в терминах функций.
Ничего себе заявочки )
G>Да, такова теория. Она разбивается о жестокую реальность stateless веба и запросоориентированности. G>Надо быть по-настоящему крутым архитектором чтобы обеспечить возможность такого перехода безболезненно.
А пафоса-то ) Имхо REST вообще отлично туда укладывается. Странно, тоже теория
G>Мне иерархичность модели никогда не мешала (в SQL то она не мешает). Мешают именно средства работы с этой иерархией.
Т.е. работать без средств проще, чем с ними. Превосходно.
Уважаемый gandjustas, беседовать с вами очень интересно; у вас что ни фраза, то парадокс ) надеюсь, вам это не мешает
Здравствуйте, meowth, Вы писали:
G>>Да, такова теория. Она разбивается о жестокую реальность stateless веба и запросоориентированности. G>>Надо быть по-настоящему крутым архитектором чтобы обеспечить возможность такого перехода безболезненно. M>А пафоса-то ) Имхо REST вообще отлично туда укладывается. Странно, тоже теория
Причем тут REST?
Я участвовал один раз в процессе переделки десктопного приложения в веб.
Тоже сначала говорили что только PL поменяется и все. А на деле 90% понадобилось переписать.
И если поизучать опыт других, то таких случаев окажется очень много.
G>>Мне иерархичность модели никогда не мешала (в SQL то она не мешает). Мешают именно средства работы с этой иерархией. M>Т.е. работать без средств проще, чем с ними. Превосходно.
Не выдумывай. Я не написал что мешают все средства, мешают только некоторые, такие как LL например.
Здравствуйте, gandjustas, Вы писали:
M>>По-твоему, для domain этот код плох, потому что он с слишком DTO-ориентирован, для репортинга плох, потому что не такой же, как для domain, хотя и лезет в domain, а для presentation layer я так и не понял почему плох, но у тебя он вызвал сильное отторжение. G>Это ты что-то придумал.
Ничего не придумал, вы сами сказали следующее: "G>>>Ага, теперь нам надо разный код писать для работы с товарами категории X в domain и в reporting."
G>Только для этого надо поднять в память сначала весь объект. А это может быть непозволительно долго.
Весь не надо, есть проекции и срезы. Кроме того, инфраструктура обеспечивает совершенно прозрачный для бизнес-скрипта кэш объектов.
G>Кроме того, если нужны запросы с аггрегатными операциями, что придумаете?
Придумывать ничего не надо, надо написать запрос с аггрегатными операциями.
Здравствуйте, gandjustas, Вы писали:
G>>>Да, такова теория. Она разбивается о жестокую реальность stateless веба и запросоориентированности. G>>>Надо быть по-настоящему крутым архитектором чтобы обеспечить возможность такого перехода безболезненно. M>>А пафоса-то ) Имхо REST вообще отлично туда укладывается. Странно, тоже теория : G>Причем тут REST?
При том, что это теория, но о "жестокую реальность" не разбивается, вполне мирно сосуществует.
G>Я участвовал один раз в процессе переделки десктопного приложения в веб. G>Тоже сначала говорили что только PL поменяется и все. А на деле 90% понадобилось переписать. G>И если поизучать опыт других, то таких случаев окажется очень много.
Здесь спорить не буду, ибо может у вас все по-другому. Мне ни разу не встречалось, ничего не могу сказать. Имхо anemic только для этого и хорош -- если вдруг ВНЕЗАПНО надо идти в web, а DTO писать "ломает". Кстати я смотрю, "только один раз".
G>>>Мне иерархичность модели никогда не мешала (в SQL то она не мешает). Мешают именно средства работы с этой иерархией. M>>Т.е. работать без средств проще, чем с ними. Превосходно. G>Не выдумывай. Я не написал что мешают все средства, мешают только некоторые, такие как LL например.
В другом посте вы сказали, что для anemic тоже есть инфраструктура, обеспечивающая persistence ignorance. LL -- это ее важная часть. А тут вдруг оказывается, что LL -- мешает. Интересная у вас логика. Об ее "жестокуюю реальность" "разбивается" моя точка зрения )
Здравствуйте, meowth, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>>>Да, такова теория. Она разбивается о жестокую реальность stateless веба и запросоориентированности. G>>>>Надо быть по-настоящему крутым архитектором чтобы обеспечить возможность такого перехода безболезненно. M>>>А пафоса-то ) Имхо REST вообще отлично туда укладывается. Странно, тоже теория : G>>Причем тут REST? M>При том, что это теория, но о "жестокую реальность" не разбивается, вполне мирно сосуществует.
Теория заключается в том что в обычном двузвенном десктоп приложении при переделке в веб придется переписать только PL.
Практика заключается в том что таких случаев до смешного мало, переписывать приходится до 90%.
G>>Я участвовал один раз в процессе переделки десктопного приложения в веб. G>>Тоже сначала говорили что только PL поменяется и все. А на деле 90% понадобилось переписать. G>>И если поизучать опыт других, то таких случаев окажется очень много. M>Здесь спорить не буду, ибо может у вас все по-другому. Мне ни разу не встречалось, ничего не могу сказать. Имхо anemic только для этого и хорош -- если вдруг ВНЕЗАПНО надо идти в web, а DTO писать "ломает". Кстати я смотрю, "только один раз".
Все неожиданные требования появляются внезапно.
G>>>>Мне иерархичность модели никогда не мешала (в SQL то она не мешает). Мешают именно средства работы с этой иерархией. M>>>Т.е. работать без средств проще, чем с ними. Превосходно. G>>Не выдумывай. Я не написал что мешают все средства, мешают только некоторые, такие как LL например. M>В другом посте вы сказали, что для anemic тоже есть инфраструктура, обеспечивающая persistence ignorance.
не надо выдумывать. я говорил что в anemic используются теже средства persistance, что и для rich. Какую функциональность этих средств использовать — отдельный вопрос.
Мне вот непонятно, почему рассуждая о Rich модели и о Фаулере, всегда забывают о ряде моментов.
Во-первых, бизнес-логика, связанная с, скажем, организацией, необязательно должна быть защита в класс Организация — если эта логика внешняя по отношению к организации, например набор бизнес-правил, оно может (и должна быть) представлена в виде отдельных бизнес-сущностей. Во-вторых помимо собственно domain, у Фаулера есть еще такая штука как infrastructure.
Хотя это вообще шутка сугубо декоративная. Я напишу себе экстеншин методы и у меня вариант 1 превратится в вариант 2. Это какая модель тогда будет? А если организацию при создании параметризировать сервисом, вызов в который она будет делегировать для получения списка емплоееров?
Здравствуйте, Mike Chaliy, Вы писали:
MC>Если это станет проблемой, а оно не станет, как я говорил у нас кеши. Мы прикрутим кастомный репорт.
Ага, а потом поставим приложение на веб-ферму или кластер и — упс — накрылись медным тазом наши кэши... Лично я больше всего ненавижу рич модель именно за эти кэши, которые при развитии проекта всегда путаются под ногами...
Здравствуйте, meowth, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
M>>>По-твоему, для domain этот код плох, потому что он с слишком DTO-ориентирован, для репортинга плох, потому что не такой же, как для domain, хотя и лезет в domain, а для presentation layer я так и не понял почему плох, но у тебя он вызвал сильное отторжение. G>>Это ты что-то придумал. M>Ничего не придумал, вы сами сказали следующее: "G>>>Ага, теперь нам надо разный код писать для работы с товарами категории X в domain и в reporting."
Я констатировал факт.
G>>Только для этого надо поднять в память сначала весь объект. А это может быть непозволительно долго. M>Весь не надо, есть проекции и срезы. Кроме того, инфраструктура обеспечивает совершенно прозрачный для бизнес-скрипта кэш объектов.
Да ну? И как делать проекции и срезы с domain model? А в кеш не полностью объекты тянутся?
G>>Кроме того, если нужны запросы с аггрегатными операциями, что придумаете? M>Придумывать ничего не надо, надо написать запрос с аггрегатными операциями.
Ну а как же domain model? Что там поймет domain expert?
Или снова получается что самая rich модель является таковой процентов на 5-10?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, GlebZ, Вы писали:
ВВ>Во-первых, бизнес-логика, связанная с, скажем, организацией, необязательно должна быть защита в класс Организация — если эта логика внешняя по отношению к организации, например набор бизнес-правил, оно может (и должна быть) представлена в виде отдельных бизнес-сущностей.
И как такой класс назвываться будет? Думаете в предметной области будет такое понятие, как вы придумаете для этого класса?
ВВ>Во-вторых помимо собственно domain, у Фаулера есть еще такая штука как infrastructure.
Это то что не бизнес-логика.
ВВ>А все отличия сводятся к: ВВ>Employer[] OrganizationService.GetEmployers(Organization org){…} ВВ>Employer[] Organization.GetEmployers(){…}
Это только в самом простом случае.
ВВ>Хотя это вообще шутка сугубо декоративная. Я напишу себе экстеншин методы и у меня вариант 1 превратится в вариант 2. Это какая модель тогда будет?
Все равно anemic.
ВВ>А если организацию при создании параметризировать сервисом, вызов в который она будет делегировать для получения списка емплоееров?
Это будет уже идиотизм. Так как сущности окажутся привязаны к сервисам без необходимости. А в остальном код такой же как в anemic будет.
Здравствуйте, gandjustas, Вы писали:
M>>Ничего не придумал, вы сами сказали следующее: "G>>>Ага, теперь нам надо разный код писать для работы с товарами категории X в domain и в reporting." G>Я констатировал факт.
Ну а я его опроверг
G>>>Только для этого надо поднять в память сначала весь объект. А это может быть непозволительно долго. M>>Весь не надо, есть проекции и срезы. Кроме того, инфраструктура обеспечивает совершенно прозрачный для бизнес-скрипта кэш объектов. G>Да ну? И как делать проекции и срезы с domain model? А в кеш не полностью объекты тянутся?
Очень просто. Читайте NHibernate API и справочник по HQL. Читайте там, я уже писал, что в кеше лежат "т.н. deghydrated objects", разобранные на данные. Тянутся так, как вы напишете.
G>Ну а как же domain model? Что там поймет domain expert? G>Или снова получается что самая rich модель является таковой процентов на 5-10?
Не заметил противоречий. В HQL аггрегаты поддерживаются наравне с domain query, для domain expert никакой разницы не наблюдается.
Пример:
"from SomeItems as si select si, count(si.children)".List();
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Лобанов Игорь, Вы писали:
ЛИ>>Хотел бы подвергнуть сомнению все эти пункты: ЛИ>>1) Хорошо приготовленная RDM в этом смысле превосходит ADM, и Вы перечислили причины почему в той части, где говорите о преимуществах RDM; GZ>Тут я бы проитерполировал сложность сопровождения в зависимости от количества сущностей. При большом количестве, RDM должен быть эффективней. Но RDM также приводит к более высоким требованиям по качеству архитектуры и качеству дизайна.
Это безусловно. Одно из преимуществ ADM -- простота дизайна в смысле нетребовательности к квалификации разработчиков и проектировщиков.
ЛИ>>2) Переносимость бизнес-объектов между физическими звеньями (то есть за границы адресного пространства) -- довольно редкое требование, нет необходимости ориентироваться на него в общем случае. Использование бизнес-объектов RDM в разных слоях в пределах одного физического звена при адекватных инструментах никакой проблемы не составляет; GZ>В паттернах Фаулера есть ключевое слово Enterprise о котором часто забывают. А это практически всегда означает, что клиенты как минимум хотят с кем-то, зачем-то интегрироваться. Поэтому переносимость нужна. А ежели объекты отчуждаемы, то это ващщее...
Полностью согласен на счёт неизбежности задачи интеграции в корпоративных информационных системах, но она чрезвычайно редко делается с помощью простой сериализации -- опасно завязывать контракт на внутренней структуре классов. Поэтому даже в простейшем случае так или иначе используется data binding, для которого не существенна разница между RDM и ADM.
GZ>Кроме того, даже на уровне потребления нельзя использовать голые классы. Иначе мы нарушаем изоляцию через фасад.
Честно говоря, не понял, что имеется в виду.
ЛИ>>3) Если имеют место большие объёмы данных, то лучше вообще не связываться с Domain Model. К счастью, большинство транзакционных сценариев не предполагает большого количества объектов, а значит можно в полной мере использовать преимущества RDM; GZ>В том то и дело, что ADM все это нормально переваривает без костылей.
ЛИ>>4) Постоянная валидность бизнес-объектов и RDM -- совершенно не связанные между собой аспекты, в случае ADM точно так же можно наложить ограничение постоянной валидности. GZ>В ADM это как раз сделать очень сложно.
ЛИ>>К тому же современные средства валидации бизнес-объектов поддерживают несколько степеней валидности, в зависимости от контекста. GZ>Без возражений. Только вопрос что имелось ввиду под средствами?
Про .Net не скажу, но в JEE есть несколько библиотек и целый стандарт JSR 303: Bean Validation, который описывает как с помощью аннотаций декларативно описывать присущие объекту инварианты, а так же как их валидировать.
ЛИ>>То, что Вы называете сглаживанием недостатков модели, я бы назвал просто правильным способом реализации RDM GZ>Немножко добавлю. Я — разработчик NET. В случае реализации ADM, я собираю приложения не пользуясь излишним инструментарием(ну ессно это не касается отчетов, OLAP и другой специализации). Это позволяет уменьшать сложность вхождения в проект, углубляет понимание самих процессов происходящих в решении. Я могу на коленке, собрать приложение любой степени сложности. И второе, что хотелось бы повторить. Я хочу не отвлекаться на правильность дизайна OOP. В реальности, реализация правильного дизайна OOP — весьма сложная штукенция. Можно заделать грабли.
Одно из соображений, которое я приводил у себя в блоге, это то, что без использования хорошего инструментария ORM лучше даже и не связываться с RDM, потому что выйдет сложно. В этом смысле ORM -- тот самый случай enabling technology, открывающей возможности. А вот насколько это "правильно", мне кажется, дело вкуса и личных пристрастий.
ЛИ>>P.S. Совсем недавно я писал развёрнутую статью на эту тему у себя в блоге, если любопытно: ЛИ>>http://javatoday.ru/2009/03/rich-domain-model/ GZ>Что-то уж очень страшное. Или я ваще ничего не понял, или одно из двух. У постановки может быть большое кол-во графов. Ну например, есть иерархия подчинения, типа отдел с директором, подчиненные подразделения и т.д. А есть проектные группы, которым эта иерархия ваще по барабану, так как там 3 чела с одного подразделения, 2 чела с другого. И у этих двух иерархий, независимые связи и некоторая ортогональная логика. Зачем мешать все в одном объекте? Не проще ли выделить некоторую логику в раздельные сервисы? Band of Four здря книжки писали?
Вы привели очень хороший пример, давайте только его разрисуем. Вот сущности:
1) Отдел
1.1) Ассоциация "директор" -> Работник[1]
1.2) Ассоциация "сотрудники" -> Работник[0..*]
2) Проект
2.1) Ассоциация "руководитель" -> Работник[1]
2.2) Ассоциация "участники" -> Работник[1..*]
3) Работник
3.1) Ассоциация "отдел в подчинении" (обратная сторона "Отдел.директор") -> Отдел[0..1]
3.2) Ассоциация "сотрудник отдела" (обратная сторона "Отдел.сотрудники") -> Отдел[1]
3.3) Ассоциация "проекты в управлении" (обратная сторона "Проект.руководитель") -> Проект[0..*]
3.4) Ассоциация "участвует в проектах" (обратная сторона "Проект.участники") -> Проект[0..*]
По сути, Ваш вопрос можно переформулировать: стоит ли мешать в один класс Работник все 4 ассоциации или следует разделить класс на две несвязанные половинки: "Сотрудник отдела" и "Участник проекта". Делить не стоит, потому что не смотря на полную независимость иерархий, в каких-то сценариях потребуется навигация одновременно по двум иерархиям. В случае же, когда нас интересует только один аспект Работника, механизм lazy loading гарантирует нам, что "лишние" данные вообще не будут фигурировать в операции.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, Mike Chaliy, Вы писали:
MC>>Если это станет проблемой, а оно не станет, как я говорил у нас кеши. Мы прикрутим кастомный репорт.
K>Ага, а потом поставим приложение на веб-ферму или кластер и — упс — накрылись медным тазом наши кэши... Лично я больше всего ненавижу рич модель именно за эти кэши, которые при развитии проекта всегда путаются под ногами...
А Вы используйте правильные кэши, которые дружат с кластером.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, Mike Chaliy, Вы писали:
MC>>Если это станет проблемой, а оно не станет, как я говорил у нас кеши. Мы прикрутим кастомный репорт.
K>Ага, а потом поставим приложение на веб-ферму или кластер и — упс — накрылись медным тазом наши кэши... Лично я больше всего ненавижу рич модель именно за эти кэши, которые при развитии проекта всегда путаются под ногами...
Ой, какие нехорошие кеши, путаются все время
У меня кластер из серверов приложений, ничего не путаются. Наверное, потому, что shared cache, как делают все разработчики, использующие фермы.
Здравствуйте, gandjustas, Вы писали:
G>Теория заключается в том что в обычном двузвенном десктоп приложении при переделке в веб придется переписать только PL. G>Практика заключается в том что таких случаев до смешного мало, переписывать приходится до 90%.
В таком случае что anemic, что rich -- разницы с точки зрения трудоемкости развития нету.
G>Все неожиданные требования появляются внезапно.
Не хочу спорить на эту тему. Скажу только, что у нас в проекте в документе vision практикуется раздел system evolution, где описаны evolution plans и extension points проекта; и проектирование ведется с учетом этих рисков. Это спасает от "внезапных" требований.
Здравствуйте, gandjustas, Вы писали:
ВВ>>Во-первых, бизнес-логика, связанная с, скажем, организацией, необязательно должна быть защита в класс Организация — если эта логика внешняя по отношению к организации, например набор бизнес-правил, оно может (и должна быть) представлена в виде отдельных бизнес-сущностей. G>И как такой класс назвываться будет? Думаете в предметной области будет такое понятие, как вы придумаете для этого класса?
Мне разжевать и в рот положить? Я сказал, что если логика внешняя по отношению к Организации, она не должна содержаться в классе Организация. Если эта логика внешняя, то очевидно "в предметной области" и понятие такое найдется.
ВВ>>А если организацию при создании параметризировать сервисом, вызов в который она будет делегировать для получения списка емплоееров? G>Это будет уже идиотизм. Так как сущности окажутся привязаны к сервисам без необходимости. А в остальном код такой же как в anemic будет.
Вот когда придет понимание, что привязка сущностей к сервисам куда лучше лучше чем зависимость сервисов от контрактов сущностей — что противоречит даже большинству сервис-ориентед паттернов — тогда и станет понятно, чем хороша жирная модель.
Здравствуйте, meowth, Вы писали:
M>Здравствуйте, koandrew, Вы писали:
K>>Здравствуйте, Mike Chaliy, Вы писали:
MC>>>Если это станет проблемой, а оно не станет, как я говорил у нас кеши. Мы прикрутим кастомный репорт.
K>>Ага, а потом поставим приложение на веб-ферму или кластер и — упс — накрылись медным тазом наши кэши... Лично я больше всего ненавижу рич модель именно за эти кэши, которые при развитии проекта всегда путаются под ногами...
M>Ой, какие нехорошие кеши, путаются все время M>У меня кластер из серверов приложений, ничего не путаются. Наверное, потому, что shared cache, как делают все разработчики, использующие фермы.
), то объекты и массивы — это наиболее удобный, экономный и естественный способ представления данных. Любые контейнеры данных будут заведомо более избыточны, чем объекты. Конечно, возможна экзотика, когда такой подход неприменим: например, резалтсеты разной структуры. И конечно же, само собой, то, что можно делать в базе, надо делать в базе.
