DDD с EF Code First - как их собрать?

Я изучаю разработку DDD в течение нескольких дней, и мне начинает нравиться.

I (думаю, я) понимаю принцип DDD, где основное внимание уделяется бизнес-объектам, где у вас есть агрегаты, агрегирует корни, репозитории только для агрегатов и т.д.

Я пытаюсь создать простой проект, в котором я совмещаю разработку DDD с подходом Code First.

Мои вопросы: (я использую asp.net MVC)

  • Объекты DDD Business будут отличаться от объектов Code First? Даже если они, вероятно, будут одинаковыми, например, я могу иметь бизнес-объект Product, который имеет все правила и методы, и я могу иметь первый объект кода Product (POCO), который будет содержать только те свойства, которые мне нужны для сохранения в базе данных.

  • Если ответ на вопрос 1 является "истинным", то как я могу уведомить объект Product POCO о том, что свойство из бизнес-объекта Product было изменено, и я должен его обновить? Я использую "AutoMapper" или что-то вроде этого? Если ответ "нет", я полностью потерял.

Можете ли вы показать мне самый простой (CRUD) пример того, как я могу сместить эти два?

Спасибо

ОТВЕТЫ

Ответ 1

Ответ №. Одна из лучших вещей в коде EF - во-первых, это то, что он отлично вписывается в DDD, поскольку вам нужно вручную создавать свои бизнес-объекты, поэтому используйте свои модели EF, чтобы они были эквивалентны объектам DDD и объектам ценности, Не нужно добавлять дополнительный уровень сложности, я не думаю, что DDD рекомендует что угодно.

У вас даже могут быть ваши сущности для реализации IEntity, и вы оцениваете объекты для реализации IValue, дополнительно следуете остальным шаблонам DDD, а именно, репозитории, которые выполняют фактическую связь с базой данных. Более того, вы можете найти это очень хорошее примерное приложение в .NET, хотя оно не использует код EF вначале, оно все еще очень ценно: http://code.google.com/p/ndddsample/

Ответ 2

Обновление Я больше не сторонник использования "объектов домена" и вместо этого выступаю за использование модели домена на основе обмена сообщениями. См. здесь для примера.

Ответ на # 1 зависит от этого. В любом корпоративном приложении вы найдете две основные категории в домене:

Прямой CRUD

Там нет необходимости в объекте домена здесь, потому что следующее состояние объекта не зависит от предыдущего состояния объекта. Это все данные и никакого поведения. В этом случае можно использовать один и тот же класс (т.е. EF POCO): редактирование, сохранение, отображение.

Примером этого является сохранение платежного адреса в заказе:

public class BillingAddress {
  public Guid OrderId;
  public string StreetLine1;
  // etc.
}

С другой стороны, мы имеем...

Государственные машины

Вам нужно иметь отдельные объекты для поведения домена и сохранения состояния (и репозиторий для выполнения работы). Открытый интерфейс на объекте домена должен быть почти всегда пустым и открытым. Примером этого может быть статус заказа:

public class Order { // this is the domain object  
  private Guid _id;
  private Status _status;

  // note the behavior here - we throw an exception if it not a valid state transition
  public void Cancel() {  
    if (_status == Status.Shipped)
      throw new InvalidOperationException("Can't cancel order after shipping.")
    _status = Status.Cancelled;
  }

  // etc...
}

public class Data.Order { // this is the persistence (EF) class
  public Guid Id;
  public Status Status;
}

public interface IOrderRepository {
  // The implementation of this will:
  // 1. Load the EF class if it exists or new it up with the ID if it doesn't
  // 2. Map the domain class to the EF class
  // 3. Save the EF class to the DbContext.
  void Save(Order order); 
}

Ответ на # 2 заключается в том, что DbContext автоматически отслеживает изменения в классах EF.

Ответ 3

Недавно я сделал аналогичный проект. Я следил за этим уроком: И я сделал это так: я создал Blank-решение, добавил проекты: Domain, Service и WebUI.

Проще говоря, в домене я поставил модель (например, сначала для кода EF, методы и т.д.), Служба была использована для домена для связи с миром (WebUI, MobileUI, другие сайты и т.д.), Используя asp.net webapi WebUi было на самом деле MVC-приложением (но модель была в домене, поэтому в основном это VC)

Надеюсь, я помог

Ответ 4

Курс Pluralsight: Entity Framework в Enterprise входит в этот точный сценарий разработки Driven Driven Design, который включен в EF Code First.

Для номера 1, я считаю, вы можете сделать это в любом случае. Это просто вопрос стиля. Для номера 2, инструктор в видео проходит через пару способов объяснить это. Один из способов - иметь свойство "State" для каждого класса, установленного на стороне клиента при изменении значения. Затем DbContext знает, какие изменения сохраняются.

Ответ 5

Поздний вопрос по этой теме. Чтение ответа Джоша Кодрофф подтверждает мои мысли о реализации репозитория, например, Entity Framework DAL.

Вы сопоставляете объект домена с объектом устойчивости EF и позволяете EF обрабатывать его при сохранении. При извлечении вы позволяете EF извлекать из базы данных и сопоставлять ее с объектом домена (агрегирующим корнем) и добавляет его в свою коллекцию.

Является ли это правильной стратегией для реализации репозитория?