POCOs! = Доменные объекты?

Question

Поскольку я работаю над своим первым крупным проектом с ORM, я начал понимать, что ORM станет большим препятствием для создания объектов домена, которые выразительны и передают намерения.

ЭтоЯ понимаю, что мы не хотим, чтобы доменные объекты были просто пакетами общедоступных методов получения и установки.Кроме того, я начинаю понимать, что просто наличие IList повсеместно не передает намерений и может привести к злоупотреблениям со стороны разработчиков, использующих эти объекты.Например, может быть, лучше выставить ReadOnlyCollection .(Между прочим, я использую .NET и Entity Framework.) И вместо IList я обнаружил, что хочу представить список объектов, которые получены из MyDomainObject.(Ничто из этого не легко сделать в EF. Может быть, мне нужно использовать NHibernate или ADO.Net.)

Мои вопросы: не захожу ли я слишком далеко, пытаясь создать доменные объекты таким образом?Должны ли эти проблемы быть частью какого-то другого компонента приложения?Или у меня должен быть «реальный» объект предметной области (который имеет выразительный материал) и «тупой» объект POCO, который гидратируется ORM?

---

(Правка: Система съела кучу моих угловых скобок.)

Answer 1

Я считаю, что вы позволяете EF делать свое дело и создавать POCO на халяву. Вы также можете назвать их DTO - их роль - быть мостом от памяти к постоянству и обратно. Что касается вашего «домена», я никогда не верил, что ваша схема БД отражает целостную модель домена. В результате я всегда создавал слой «Домен» поверх слоя «Постоянство» (или хранилище), который представляет бизнес-домен, не допуская фабрику колбасных изделий, которая представляет собой «Постоянство». Этот слой домена может объединять ваши DTO по мере необходимости, чтобы создать ориентированную на разработчика модель, которая имеет смысл. Используйте фабричный шаблон для создания объектов Domain из DTO и наоборот - не допускайте DTO из клиентского кода, чтобы можно было изолировать изменения схемы от потребителей.

Это больше работы, больше кода отображения и т. Д., Но оно того стоит - EF уже сокращает ваш код, и я бы сказал, что на самом деле вы должны уделять время кодированию логики и представления домена, это то, что делает вас лучше, чем код инструмент генерации:)

Удачи.

Answer 2

Я пытался использовать POCO в нескольких проектах в качестве объектов домена, и, честно говоря, это работает только для простых / небольших проектов.

Я люблю ORM и не перестану их использовать.Но я всегда строю слой домена поверх слоя orm / repository.И я создаю конкретные доменные объекты, которые используются в моем приложении.Я использую структуру сопоставления, такую ​​как automapper , для преобразования объектов домена в / из объектов данных.

Я рекомендую вам прекратить использование POCO, если вы используете структуру сущностей, и позволить EF генерировать данныеобъекты для вас.Затем вместо этого создайте доменные объекты и позвольте automapper обрабатывать сопоставления в слое вашего домена.

Это немного сложнее, но с ним проще и удобнее работать.

Answer 3

Это действительно хороший вопрос - и кое-что, что я осознал, пытаясь использовать ORM для доменных объектов. Мои доменные объекты предоставляют открытые свойства типа IEnumerable, которые возвращают ReadOnlyCollection, поэтому единственный способ добавить в коллекцию - вызвать пользовательский метод Add для родительского объекта.

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

Я полностью оправдываю попытки максимально инкапсулировать ваши объекты, сохраняя поля закрытыми и предоставляя открытые методы, которые являются атомарными, явно показывают намерение и гарантируют, что объекты могут существовать только в допустимом состоянии. Если это означает использование сырого ADO.NET, пусть будет так. На мой взгляд, сохранение доменных объектов в строгом дизайне не должно быть скомпрометировано выбором технологии DAL.

Однако, я НЕНАВИЖУ, пишу код DAL котельной плиты и пишу сырой ADO.NET с sprocs в мои дни. Я пришел к выводу, что написание DAL для инкапсулированных доменных объектов становится НАМНОГО, НАМНОГО проще, если вы используете Event Sourcing в качестве механизма сохранения для своих доменных объектов. Все, что вам нужно, это таблица событий, в которой все ваши события хранятся в виде сериализованных данных. Поскольку сами доменные объекты не сохраняются, не имеет значения, что репозитории не имеют доступа к свойству List объекта домена. Затем ваша единица работы «вызывает» эти события, которые может обрабатывать компонент запроса, что будет заполнять / обновлять любые таблицы, которые вам нужны, используя простые DTO и ORM.

Вот пример источника событий

CQRS & Event Sourcing фактически разработан для обеспечения высокой масштабируемости и по определению включает в себя множество асинхронных операций, основанных на «в конечном итоге непротиворечивой» парадигме. Однако даже при работе над проектами, не требующими такого уровня масштабируемости, я обнаружил, что синхронное следование этим шаблонам обеспечивает механизм для полной инкапсуляции моих доменных объектов, при этом не нужно писать ни одной строки кода DAL, созданного вручную экономя огромное количество времени и предоставляя полный контрольный журнал (события) для каждого когда-либо предпринятого действия, добавляемого бесплатно. Это также бесценный инструмент, если вашей системе необходимо обмениваться данными со сторонними системами посредством обмена сообщениями.

Answer 4

(Ничто из этого не легко сделать в EF. Может быть, мне нужно использовать NHibernate или ADO.Net.)

Bingo.EF не поддерживает такой же уровень независимости между вашим доменом и вашей персистентной инфраструктурой, как NHibernate или специальное решение.

Что касается представленных типов, я придерживаюсь IEnumerable и использую методы Add и Remove народитель, обычно .. иногда пользовательские коллекции, но никогда не IList.

Answer 5

Ничто не говорит о том, что POCO не может содержать ваши собственные сложные объекты.Что делает POCO POCO, так это то, что он не связан с состоянием данных, а не то, что он может содержать только списки в качестве объектов.