Я немного перегружен всей информацией об DDD, блоке работы, службах домена, сервисах приложений и т. Д. Я пытаюсь понять, как в конечном итоге сохраняется неустойчивая модель домена, особенно в контексте единицы работы и Entity Framework. Скажем, у меня есть совокупный корень заказа, который я пытаюсь сохранить в моей настойчивости-невежественная моделях предметной области (ядро моего архитектурного луки):Как обрабатывать стойкость и единицу работы в DDD с помощью Entity Framework?
public class Order : EntityBase
{
public int Id { get; private set; }
public int MarketplaceId { get; private set; }
public int CustomerId {get; set;}
public List<OrderItem> Items { get; private set; }
public List<OrderComment> Comments { get; private set; }
public void AddItem(OrderItem item) { /**add item**/ }
public void AddComment(OrderComment comment) { /**add comment**/ }
public override bool Validate() { /**validate**/ }
public void Cancel() { /**cancel**/ }
}
Скажем, у меня есть процесс, который обновляет свойство на Заказать объект, например, он изменяет CustomerId, связанный с заказом.
У меня есть IOrderRepository в моем домене слоя, который будет иметь реализацию (в качестве внешнего слоя) с функцией, как это:
Order GetOrder(int orderId)
{
//get entity framework order, items, etc.
//map to domain-layer order and return domain-layer order
}
void UpdateOrder(Order order)
{
//get ENTITY FRAMEWORK order, order items, order comments, etc.
//take DOMAIN order (passed in to this function), and update EF items fetched above
//use a single EF unit of work to commit these changes
}
Там что-то не так с моим подходом. Функция UpdateOrder кажется тяжелой для небольшого изменения; но также кажется, что я должен это сделать, если мой репозиторий не знает, какие элементы в модели, не поддерживающей сохранение, изменились. Должен ли я обрабатывать все типы обновлений в отдельной функции репозитория? UpdateMarketplace (int marketplaceId), UpdateCustomer (int customerId)?
Как я набираю это, мне также интересно ... может быть, способ, которым я это выше, не слишком тяжелый? Если я изменю одно свойство, хотя я все это делаю, возможно, Entity Framework распознает, что назначенные значения одинаковы и отправит только одно обновление столбца db в SQL?
Как я могу взять модель домена моего заказа (выборка достаточно проста), выполнить некоторые операции или операции над ним, которые могут быть ограничены в области видимости, а затем сохранить модель с помощью Entity Framework?
Спасибо за ввод. Разве это не было бы более активной моделью записи? Что делать, если мои объекты домена не имеют отношения свойств 1: 1 с моими объектами базы данных? Не будет ли отображение объектов напрямую означать, что я тогда буду связываться с отношением 1: 1 и в некотором смысле связать мою модель домена с ее постоянством? – Josh
Вы не будете полностью привязаны к соотношению 1: 1, потому что сопоставления довольно гибкие при использовании подхода, основанного на кодах. Но вы можете столкнуться с проблемами и почувствовать, что вы делаете картографирование 1: 1, что, конечно, плохо. Вы все еще можете сделать еще один слой и перевести между ними, однако вы потеряете часть автоматического отслеживания изменений. –
При переводе с объекта домена на объект данных, знайте EF, вам нужно будет прикрепить его к контексту, вызвав Attach и изменив его состояние. Затем он будет сохранен при вызове SaveChanges. См. Эту [ссылку] (http://msdn.microsoft.com/en-US/data/jj592676). См. Шаблоны UOW/Repository, с которыми я связан в своем сообщении. Они также содержат методы для этих видов операций. –