Рекомендации по отображению объектов на объекты домена

Ответ 1

Чтобы ваше приложение и ваш разум в долгосрочной перспективе, НИКОГДА НЕ запускайте свое приложение DDD с проблемами, связанными с персистентностью (что-то дБ, что такое orm и т.д.) и ВСЕГДА (да, всегда) коснитесь db как последний этап разработки.

Модель вашего домена и фактически любая другая модель, кроме сохранения. Используйте шаблон репозитория, чтобы отключить приложение из Persistence. Определите интерфейс репо по мере необходимости приложением и не привязывайте его к методу доступа к db (то, почему вы выполняете персистентность позже, поэтому вы не получите соблазн связать ваше приложение с данными о сохранении).

Записывайте в операторы памяти для интерфейсов репо, это обычно означает простую оболочку над списком или словарем, поэтому ОЧЕНЬ быстро писать и, что более важно, тривиально изменить. Используйте те, которые действительно тестируют и разрабатывают приложение.

После того, как интерфейсы стабильны и приложение работает, пришло время написать реализацию персистентности, где вы можете использовать все, что пожелаете. В вашем случае EF и там оно появляется.

Теперь, это очень субъективно, нет правильного или неправильного пути, там, где вы предпочитаете делать что-то.

Лично у меня есть привычка использовать mementos, поэтому я получаю память от объекта домена, а затем вручную сопоставляю ее с объектами (микро) ORM. Причина, по которой я делаю это вручную, состоит в том, что мои объекты mementos содержат объекты значений. Если бы я использовал AutoMapper, мне было бы нужно его скрыть, и в сущности я бы написал больше кода, чем вручную.

Обновление (2015)

В эти дни я просто Json-объект и либо использую определенную модель чтения, либо храню ее непосредственно в модели чтения с столбцом Data, который содержит сериализованный объект. Я использую Mementos только для очень конкретных случаев. </Обновление >

В зависимости от того, как выглядят объекты вашего домена и как выглядят объекты EF, вы можете уйти с использованием automapper для большей части отображения. Тем не менее, вам будет сложнее тестировать ваши репозитории.

Для вас это , как, вы можете найти способ, которым он подходит вашему стилю, и он легко ремонтируется, но НИКОГДА никогда не создавайте или не изменяйте объекты вашего домена, чтобы быть более совместимыми или соответствовать объектам ORM. Это не об изменении баз данных или ORM, а о том, что Домен (и остальная часть приложения) должным образом отделен от данных Persistence (которые ORM есть).

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

Ответ 2

Почему бы вам просто не использовать объекты EF как объекты Domain, так как вы просматриваете сначала код Entity Framework 6? Поэтому сначала вы создаете структуру Domain Model, а затем структуру базы данных.

Я использую NHibernate и считаю, что в EF вы также можете указать правила сопоставления из таблиц DB в свои объекты POCO, особенно с EF6. Это дополнительное усилие для разработки другого слоя абстракции над объектами EF. Пусть ORM несет за это ответственность.

Я не согласен с этой статьей, что вы можете читать "Entity Framework 5 с шаблоном AutoMapper и Repository" и многие другие статьи, в которых люди просто используют объекты EF как объекты домена:

• Создание модели данных Entity Framework для приложения ASP.NET MVC (1 из 10)
• SO question "Разработка под управлением домена и платформа Entity Framework 4.1 (сначала кодовая)"
• Общая информация о DDD "Разработка и развитие домена на практике"
• Первый подход к платформе Entity Framework и дизайн, основанный на домене

AutoMapper определенно поможет вам, когда вы начнете создавать слой презентации и столкнетесь с множеством моделей просмотра пользовательского интерфейса. Это полезно при создании анемичных моделей и немного бесполезно с объектами реального домена, когда нет публичных сеттеров.

Есть старый пост от Jimmy Bogard "Случай для двустороннего сопоставления в AutoMapper" , где он сообщает, что "There is no two-way mapping because we never need two-way mapping."

Итак, для чего мы используем AutoMapper? Наши пять профилей включают:

• От домена до ViewModel (сильно типизированные модели просмотра для MVC)
• Из домена в EditModel (сильно типизированные модели просмотра для форм в MVC)
• От EditModel до CommandMessages - переход от слабо типизированного EditModel к строго типизированным, разбитым сообщениям. Единый EditModel может генерировать полдюжины сообщений.
• От домена к ReportModel - строго типизированные отчеты Telerik
• От модели "Домен в EDI" - сплющенные модели, используемые для генерации отчетов EDI.

Ответ 3

О нет, я бы не добавил этот дополнительный слой вообще.

NHibernate и Entity Framework Code-First (я бы использовал EF) были предназначены для решения этой точной проблемы - сопоставление объектов домена с вашей реляционной моделью (которые не имеют одинаковых ограничений на их дизайн, поэтому могут и вероятно, будет другой формой).

Просто стыдно тратить отличные способности отображения EF и заменять его чем-то другим, даже AutoMapper.