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 извлекать из базы данных и сопоставлять ее с объектом домена (агрегирующим корнем) и добавляет его в свою коллекцию.
Является ли это правильной стратегией для реализации репозитория?