Здравствуйте, Ziaw, Вы писали:
Z>Реально из недостатков rich модели я могу пречислить следующие:
Z>1. Бизнесметоды меняются и нам приходится иногда держать несколько вариантов одного и того-же бизнесметода в модели. Решается стратегией. В примере Save() добавляем метод Save(IPersister persister). Save() объявляем депрекейтед и сокращаем его использование до минимума.
Странно что все приколупались к этому методу Save. В доменных моделях уже давно практикуеться паттерн репозитарий. Упрощенно это класс уровня бизнеслогики который управляет сохранением и доставанием сущности откуданибыло. Важно понимать что он упровляет. Тоесть реально работу выполняет стандарный ДАЛ. Вобщемто применение этого паттерна сразу же убивает наповал аргумент автора статьи по поводу сохранения в БД/сериализации. Точно также он убивает агрумент про SRP. А еще в отличии от анмеичных моделей этот паттерн четко отвечает на вопрос как мне заперсистить сущность. И все на одном слое. И все понятно по коду.
Здравствуйте, Blazkowicz, Вы писали:
B>- Anemic не отменяет поведения объекта, а лишь ограничивает его, для того чтобы минимизировать зависимости объекта. У Фаулера, например, Domain зависит от Repository. Странно как-то.
Репозитарий Фаулера(точнее даже Ерика Еванса) это часть бизнеслогики.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Blazkowicz, Вы писали:
B>>Как планируется решать эту проблему? IB>1. Все-таки в таких случаях большой DTO, агрегирующий все нужные данные, мне наиболее симпатичен. Такой сценарий возникает только тогда, когда надо выгрузить большей объем данных для оффлайновой работы.
Такой сценарий возникает всегда. От обьема данных это не зависит. У кастомера — адреса, у ордера — айтемы. IB>Это совершенно отдельный самостоятельный юз-кейс и логично, что под него нужен отдельный набор данных, тем более, что в этом наборе вполне себе переиспользуются структуры созданные ранее, под другие задачи.
Нет, например глупо выгружать на клинет внутренние айдишники оредер айтемов (тех что от ордера)? Да и вы сами дальше говорите про таймстампы. Или у вас в "стройной" моделе будут еще и таимстампы? И вообще что это за фишка внутреннюю модель системы показывать как публичный контракт? Типа для изменениня бизнеспроцеса поменть версию публичного контракта? Ндя. IB> Более того, это уже не совсем DTO, так как в нем будут содержаться персистентные данные относящиеся непосредственно к синхронизации, типа таймстампов. IB>2. В REST этой проблемы, по идее, нет.
Ну и казалось причем тут РЕСТ и синхронизация?
B>>Очевидно, что ORM не единственный инструментарий, который требует от нас именно "жирной" модели данных. IB>Инструментарии мне совершенно параллельны, мне интересны сценарии. А вот сценариев где "жирная" модель удобнее "стройной" очень мало. Скажем, в вышеприведенном "жирная" модель пролетает со свистом, так как просто некуда впихнуть те же таймстампы.
Насколько я понял (я не нашел гдето упоминания слова "синхронизация") вы сами придумали необходимость таймстампов?
Иначе говоря над жирными моделями всегда есть фасады. А фасады возвращают ДТО. Будет ли это ремот фасад или просто сервис лэер роли не играет. У нас уже есть ДТО с достаточным уровнем деталиации. Никуда вобщемто жирная модель не пролитает.
Здравствуйте, Mike Chaliy, Вы писали:
MC>Репозитарий Фаулера(точнее даже Ерика Еванса) это часть бизнеслогики.
Вообще-то это совсем не так. Эванс как раз настаивает на выделении Домен Модели от всего остального (в т.ч. числе и от "инфраструктуры" или "репозитория") именно как центрального слоя бизнес-логики.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, Mike Chaliy, Вы писали:
MC>>Репозитарий Фаулера(точнее даже Ерика Еванса) это часть бизнеслогики.
ВВ>Вообще-то это совсем не так. Эванс как раз настаивает на выделении Домен Модели от всего остального (в т.ч. числе и от "инфраструктуры" или "репозитория") именно как центрального слоя бизнес-логики.
Вообще-то это именно так . Репозитарий это часть доменной модели. Если смотреть это с точки зрения реальных вещей, то это папка с ордерами. Ну а уже то как она реализована эта папка моделлеров не интересует. Репозитарий может обращаться к выделенному ДАЛ, а может быть постороен на ОРМ.
Посмотрите на http://dddsample.sourceforge.net/ это офциальный пример. Посмтрите где располгаються и как располагаються репозитарии. Обратите внимание что они работают с обьектами модели, если бы это был ДАЛ он бы возвращал рекорды(ДТО).
Или саму книгу. Вы найдете там упоминания про виртуальные колекции и тому подобное. Это все не характеристики ДАЛ. И они не выносятся на другой слой.
Хорошый список заблужений включая и это есть на http://tech.groups.yahoo.com/group/domaindrivendesign/. На него обычно ссылаються когда задают вопросы по типу можно ли ссылаться из модели на репозатарии. Но к сожалению я не могу его найти.
Здравствуйте, Mike Chaliy, Вы писали:
MC>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Здравствуйте, Mike Chaliy, Вы писали:
MC>>>Репозитарий Фаулера(точнее даже Ерика Еванса) это часть бизнеслогики.
ВВ>>Вообще-то это совсем не так. Эванс как раз настаивает на выделении Домен Модели от всего остального (в т.ч. числе и от "инфраструктуры" или "репозитория") именно как центрального слоя бизнес-логики.
MC>Вообще-то это именно так . Репозитарий это часть доменной модели. Если смотреть это с точки зрения реальных вещей, то это папка с ордерами. Ну а уже то как она реализована эта папка моделлеров не интересует. Репозитарий может обращаться к выделенному ДАЛ, а может быть постороен на ОРМ.
Ну если мы говорим именно об Эвансе, то у него есть понятие infrastructure, который "provides generic technical capabilities that support the higher layers: message sending for the application, persistence for the domain, drawing widgets for the UI.
Тогда как Домен responsible for representing concepts of the business, information about the business situation, and business rules.
А объясняя, почему тут есть разделение Эванс ссылается на Фаулера
Separating the domain layer from the infrastructure and user interface layers allows a much
cleaner design of each layer. Isolated layers are much less expensive to maintain, because they
tend to evolve at different rates and respond to different needs. The separation also helps with
deployment in a distributed system, by allowing different layers to be placed flexibly in different
servers or clients, in order to minimize communication overhead and improve performance
И, честно говоря, мне это кажется логичным. На фига инфраструктуру засовывать в бизнес-слой?
MC>Посмотрите на http://dddsample.sourceforge.net/ это офциальный пример. Посмтрите где располгаються и как располагаються репозитарии. Обратите внимание что они работают с обьектами модели, если бы это был ДАЛ он бы возвращал рекорды(ДТО).
Примерчик посмотрю.
MC>Или саму книгу. Вы найдете там упоминания про виртуальные колекции и тому подобное. Это все не характеристики ДАЛ. И они не выносятся на другой слой.
DDD? Посмотрел См. выше.
MC>Хорошый список заблужений включая и это есть на http://tech.groups.yahoo.com/group/domaindrivendesign/. На него обычно ссылаються когда задают вопросы по типу можно ли ссылаться из модели на репозатарии. Но к сожалению я не могу его найти.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, Mike Chaliy, Вы писали:
MC>>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>>Здравствуйте, Mike Chaliy, Вы писали:
MC>>>>Репозитарий Фаулера(точнее даже Ерика Еванса) это часть бизнеслогики.
ВВ>>>Вообще-то это совсем не так. Эванс как раз настаивает на выделении Домен Модели от всего остального (в т.ч. числе и от "инфраструктуры" или "репозитория") именно как центрального слоя бизнес-логики.
MC>>Вообще-то это именно так . Репозитарий это часть доменной модели. Если смотреть это с точки зрения реальных вещей, то это папка с ордерами. Ну а уже то как она реализована эта папка моделлеров не интересует. Репозитарий может обращаться к выделенному ДАЛ, а может быть постороен на ОРМ.
ВВ>Ну если мы говорим именно об Эвансе, то у него есть понятие infrastructure, который "provides generic technical capabilities that support the higher layers: message sending for the application, persistence for the domain, drawing widgets for the UI. ВВ>Тогда как Домен responsible for representing concepts of the business, information about the business situation, and business rules.
Все правильно. Иммено об Эвансе. И где вы тут видите противоречие тому что репозитарии это часть доменной модели?
Конкретная реализация репозитария может основываться на инфраструктурном коде (persistence for the domain — ДАЛ). Но сам репозитарий это часть доменой модели.
Это вобщемто логично что если мы моделируем реальные ордеры, то в той же модели должно быть и хранилище этих ордеров. Иначе если у нас не будет в модели чегото куда можно сохранить, как описать такой простой процес как:
1) Получить ордер (в реальном мире пришел с товаром).
2) Проверить ордер (в реальном мире мы его сверили с наличием).
3) Сохранить ордер (в реальном мире в например в папке или сейфе).
Здравствуйте, Mike Chaliy, Вы писали:
MC>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Здравствуйте, Mike Chaliy, Вы писали:
MC>>>Репозитарий Фаулера(точнее даже Ерика Еванса) это часть бизнеслогики.
ВВ>>Вообще-то это совсем не так. Эванс как раз настаивает на выделении Домен Модели от всего остального (в т.ч. числе и от "инфраструктуры" или "репозитория") именно как центрального слоя бизнес-логики.
MC>Вообще-то это именно так . Репозитарий это часть доменной модели. Если смотреть это с точки зрения реальных вещей, то это папка с ордерами. Ну а уже то как она реализована эта папка моделлеров не интересует. Репозитарий может обращаться к выделенному ДАЛ, а может быть постороен на ОРМ.
MC>Посмотрите на http://dddsample.sourceforge.net/ это офциальный пример. Посмтрите где располгаються и как располагаються репозитарии. Обратите внимание что они работают с обьектами модели, если бы это был ДАЛ он бы возвращал рекорды(ДТО).
MC>Или например почитайте тут — http://fragmental.tw/2007/11/29/repositories-misunderstandings/
MC>Или саму книгу. Вы найдете там упоминания про виртуальные колекции и тому подобное. Это все не характеристики ДАЛ. И они не выносятся на другой слой.
MC>Хорошый список заблужений включая и это есть на http://tech.groups.yahoo.com/group/domaindrivendesign/. На него обычно ссылаються когда задают вопросы по типу можно ли ссылаться из модели на репозатарии. Но к сожалению я не могу его найти.
Вот, нашел довольно четкое определение Репозитория у Эванса:
The REPOSITORY will delegate to the appropriate infrastructure services to get the job done. Encapsulating the
mechanisms of storage, retrieval, and query is the most basic feature of a REPOSITORY
implementation.
Т.е. проще говоря это "морда" для инфстрактуры, некий ее фасад. То, что я в своих "ахтунг" примерах называл persistance model. Это не часть бизнес-логики совсем.
А вот примерчик оттуда:
public class DelinquentInvoiceSpecification
{
// Basic DelinquentInvoiceSpecification code herepublic Set satisfyingElementsFrom(InvoiceRepository repository) {
//Delinquency rule is defined as:
// "grace period past as of current date"return repository.selectWhereGracePeriodPast(currentDate);
}
}
Здравствуйте, Mike Chaliy, Вы писали:
ВВ>>Ну если мы говорим именно об Эвансе, то у него есть понятие infrastructure, который "provides generic technical capabilities that support the higher layers: message sending for the application, persistence for the domain, drawing widgets for the UI. ВВ>>Тогда как Домен responsible for representing concepts of the business, information about the business situation, and business rules.
MC>Все правильно. Иммено об Эвансе. И где вы тут видите противоречие тому что репозитарии это часть доменной модели?
Ну я вот в соседнем посте еще одну цитатку привел. Репозиторий как бы фасад инфраструктуры, а доменная модель четко выделяется — причем на это в ДДД указывается неоднократно.
MC>Конкретная реализация репозитария может основываться на инфраструктурном коде (persistence for the domain — ДАЛ). Но сам репозитарий это часть доменой модели.
Гм, мне кажется при таком подходе это уже вопрос терминологии больше
Для меня эта фасад инфрастуктуры. Доменная модель как бы использует его.
MC>Это вобщемто логично что если мы моделируем реальные ордеры, то в той же модели должно быть и хранилище этих ордеров. Иначе если у нас не будет в модели чегото куда можно сохранить, как описать такой простой процес как: MC>1) Получить ордер (в реальном мире пришел с товаром). MC>2) Проверить ордер (в реальном мире мы его сверили с наличием). MC>3) Сохранить ордер (в реальном мире в например в папке или сейфе).
Вот, код как раз в тему в моем соседнем посте. Отвественный за сохранение — часть Домена, да. Но это не часть репозитория. Он использует внутри себя репозиторий.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Вот, нашел довольно четкое определение Репозитория у Эванса:
ВВ>
ВВ>The REPOSITORY will delegate to the appropriate infrastructure services to get the job done. Encapsulating the
ВВ>mechanisms of storage, retrieval, and query is the most basic feature of a REPOSITORY
ВВ>implementation.
ВВ>Т.е. проще говоря это "морда" для инфстрактуры, некий ее фасад. То, что я в своих "ахтунг" примерах называл persistance model. Это не часть бизнес-логики совсем.
Ну, не знаю. Следуя вашим словам репозитарий это дополнитильный слой между ДАЛ и бизнес логикой... реально же это такая же часть модели как и все остальное. Посмотрите примерчик который они выложили. Он реально очень многое обьясняет, например как смоделировать что в папке с ордерами может быть тока 150 ордеров.
Вот еще из книги Еванса.
But even so, take note of what has been lost. We are no longer thinking about concepts in our domain model. Our code will not be communicating about the business; it will be manipulating the technology of data retrieval. The REPOSITORY pattern is a simple conceptual framework to encapsulate those solutions and bring back our model focus.
A REPOSITORY represents all objects of a certain type as a conceptual set (usually emulated). It acts like a collection, except with more elaborate querying capability.
В этой цитате нема ничего о том где физически раположен репозитарий, этого вообще нема в книге. Но ИМХО тут вполне понятно сказано что репозитарий предназначен для моделирования, а не для сохранения.
Репозиторий — фасад инфраструктуры.
Вот в реальном приложении что ты будешь делать? Предпложим, что инфраструктура — это сохранение в БД, маппер и проч. Логично, что у тебя скорее всего будет некая отдельная библиотека, посвященная этому делу.
А теперь главный вопрос
Что эта библиотека должна "выставлять наружу"? Кучу разных интерфейсов, мапперы, классы для вызова процедур? Ну а как же изоляция? Об этом и Эванс, и Фаулер в один голос твердлят. Эванс:
Concentrate all the code related to the domain model in one layer and isolate it from the user interface, application, and infrastructure code.
Т.е. логично выставить наружу некие "фасадные интерфейсы", ведь так? И чем эти интерфейсы будут как не репозиторием?
Продолжаем цитату:
The domain objects, free of the responsibility of displaying themselves, storing themselves, managing application tasks, and so forth, can be focused on expressing the domain model.
В общем у меня лично сложилось впечатление, что репозиторий — это не часть домена
Здравствуйте, Mike Chaliy, Вы писали:
MC>В этой цитате нема ничего о том где физически раположен репозитарий, этого вообще нема в книге. Но ИМХО тут вполне понятно сказано что репозитарий предназначен для моделирования, а не для сохранения.
На самом деле этот вопрос конечно не исключающий, скажем так, интерпретацию. "Практика показывает", что в действительности удобнее делать репозиторий фасадом инфраструктуры. Ведь такой фасад так или иначе нужно.
Здравствуйте, Воронков Василий, Вы писали:
MC>>Это вобщемто логично что если мы моделируем реальные ордеры, то в той же модели должно быть и хранилище этих ордеров. Иначе если у нас не будет в модели чегото куда можно сохранить, как описать такой простой процес как: MC>>1) Получить ордер (в реальном мире пришел с товаром). MC>>2) Проверить ордер (в реальном мире мы его сверили с наличием). MC>>3) Сохранить ордер (в реальном мире в например в папке или сейфе).
ВВ>Вот, код как раз в тему в моем соседнем посте. Отвественный за сохранение — часть Домена, да. Но это не часть репозитория. Он использует внутри себя репозиторий.
Вы привели код спецификации (http://en.wikipedia.org/wiki/Specification_pattern), это обьект для инкапсуляции запросов или создания сущностей (хотя тот что вы привели тока для запросов). Но никак не сохранения. По ходу, и спецификация это тоже обьект модели.
Domain services are expressed in terms of the ubiquitous language and the domain types, i.e. the method arguments and the return values are proper domain classes. Sometimes, only the service interface (what the service does) is part of the domain layer, but the implementation (how the service does it) is part of the application layer. This is analogous to how repository interfaces are part of the domain layer, but the Hibernate implementations are not.
Yes. Typically a DAO ("data access object") is an
object that belongs to the layer between your domain
objects and their persistent datastore and has the
resposibility of marshalling data between the domain
objects and the datastore, encapsulating the domain
objects from the implementation details of the
datastore.
A repository, on the other hand, is a concept that
embodies a collection of contexts, aggregates, and/or
domain objects.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, Mike Chaliy, Вы писали:
MC>>Ну, не знаю. Следуя вашим словам репозитарий это дополнитильный слой между ДАЛ и бизнес логикой...
ВВ>Кстати, Фаулер:
ВВ>
ВВ>A Repository mediates between the domain and data mapping layers
Одно другому не мешает . Ктомуже Фолер про это пишет с технической точки зрения, а Еванс с точки зрения моделирования.
В общем и целом я с тобой согласен. Мы не сошлись тока в том можно ли репозитарий считать бизнес логикой или нет... Но мы получаем деньги не за то что "счетаем", а за то что делаем. А делаем судя по всему очень даже похоже .
Здравствуйте, Mike Chaliy, Вы писали:
MC>Так это же преимущество доменной модели. В отличии от анемичной, она вообще не завист от БД. Это более чем нормально строить отдельные доменные области для разныех областей применения промапленные на одни и теже физичиские данные. Если есть описанный рекваирмент, то вообще не проблема создать одну модель для склада (ордер и чаилдами ввиде ордер айтемс) и вторую для менеджера (товар, а к ниму ридонли прилинкованы ордер айтмс).
MC>Более того в анемичной такая схема выходит значительно сложней.
Не вижу никакой сложности. Не вижу зависимости от БД в анемичной модели. Что ты называешь "доменной моделью"? Как она взаимодействует с персистентным состоянием? MC> Я думаю вам легко будет представить себе модель в которой ордер айтемс для модели склада значительно отличаеться от ордер айтмс для менеджера.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, IB, Вы писали:
ВВ>>Save в БД тоже во всем том же отдельном лаере. IB>Нет уж, ты от темы не увиливай, ты двавай за свои слова отвечай. IB>Куда пихать второй Save, если первый не в отдельном?
Это он так витиевато пытается донести вот такой простой пример:
public class Order<T>: OrderBase
where T: OrderPersister, new
{
private static T MyPersister = new T();
public void Save()
{
MyPersister.Save(this);
}
}
public class DBOrderPersister: OrderPersister
{
public override void Save(OrderBase order)
{
...
}
}
public class XMLOrderPersister: OrderPersister
{
public override void Save(OrderBase order)
{
...
}
}
...
var dbOrder = new Order<DBOrderPersister>();
dbOrder.Save(); // ура! уехало в базу.var cmlOrder = new Order<XMLOrderPersister>();
xmlOrder.Save(); // типа уехало в XML
А избегает он приводить этот пример полностью по очень простой причине: получится чудовищно многословный и неудобный бред. Обрати внимание, что мы не смогли обойтись одним классом Ордера, даже шаблонным — иначе персистер ничего не сможет сохранить. И всё это только ради того, чтобы можно было писать dbOrder.Save().
Далее, невооруженным мозгом можно понять, что у нас классы Order<T> несовместимы между собой, т.е. я не могу сделать Load из DB, а Save — в XML.
На этот вопрос ВВ тоже уже отвечал, хоть и невнятно — он предлагает в таких случаях делать специальный OrderPersister, который умеет работать обоими путями. Мне, правда, совершенно непонятно, каким образом передать в order.Save() информацию о том, куда именно сохраняться. Но ВВ это не останавливает — он жжот, как дуговая сварка. Неважно, что это всё неудобно — главное, что ты, Ваня, тупой. Ты почему-то не догадываешься до выноса функционала из метода Order.Save, с оставлением сигнатуры на месте. Ты вот, считай, пишешь в своей статье, что лыжи и гамак для секса непригодны. А ВВ рассказывает тебе, что ежели упереться левой лыжей в опору гамака, а правую вытянуть вдоль тела, то, при определенной сноровке можно добиться секса, "практически лишенного недостатков лыжно-гамаковой модели".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Mike Chaliy, Вы писали:
IB>>Это совершенно отдельный самостоятельный юз-кейс и логично, что под него нужен отдельный набор данных, тем более, что в этом наборе вполне себе переиспользуются структуры созданные ранее, под другие задачи. MC>Нет, например глупо выгружать на клинет внутренние айдишники оредер айтемов (тех что от ордера)? Да и вы сами дальше говорите про таймстампы. Или у вас в "стройной" моделе будут еще и таимстампы? И вообще что это за фишка внутреннюю модель системы показывать как публичный контракт?
Откуда взялась внутренняя модель?
Речь идет о построении внешней модели под конкретный случай. Да, мы изобретаем специальный DTO "Ордер с айтемами" и отдаем его. MC>Типа для изменениня бизнеспроцеса поменть версию публичного контракта? Ндя.
А как вы хотели? Если реальность поменялась?
MC>Ну и казалось причем тут РЕСТ и синхронизация?
При том, что в РЕСТ нет проблемы сверхжесткости контракта, придуманной идиотами-авторами SOAP. Контракт в REST легко расширять обратно совместимым образом.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, IB, Вы писали: ВВ>>А по поводу — "полиморфизм классов" и "родовые отношения". Что конкретно непонятно? IB>Конкретно непонятно, что эти термины означают и что ты вообще имеешь ввиду, когда говоришь "объектно-ориентировано".
Я короче понял, Ваня. Тут пришли два мега-гуру архитектуры. Мы оба сынки по сравнению с ними. Предлагаю оставить Майка с ВВ обсуждать правильное разграничение репозитория и модели, а также способы сохранить жирность модели путём выноса всех ссылок в отдельные сущности доменной модели.
Мой ахтунгометр зашкалило еще 50 постов назад, поэтому я ставлю автопометку на эту тему.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
. Репозитарий это часть доменной модели. Если смотреть это с точки зрения реальных вещей, то это папка с ордерами. Ну а уже то как она реализована эта папка моделлеров не интересует. Репозитарий может обращаться к выделенному ДАЛ, а может быть постороен на ОРМ.
.
