Борьба с DDD, шаблоном репозитория и моделями связанных доменов - PullRequest
Новая
       19

Борьба с DDD, шаблоном репозитория и моделями связанных доменов

2 голосов
/ 29 января 2009

Я действительно изо всех сил пытаюсь обернуть голову вокруг некоторых из этого материала. Позвольте мне привести пример того, где я борюсь.

Я использую Linq-2-Sql в качестве DAL для своего приложения и шаблон IRepository, используемый в образце приложения MVC Storefront от Роба Конери.

В моем домене есть модель клиента, в которой есть коллекция моделей адресов. В моем пользовательском интерфейсе есть кнопка, которая позволяет пользователю добавить новый адрес для клиента. Это открывает редактор адресов, который позволяет им заполнить всю информацию.

Что будет дальше? Сохраняется ли адрес в базе данных, затем добавляется в список в моем объекте customer? Он просто добавляется в список, но не обновляется, пока объект Customer не будет сохранен? Что делать, если пользователь хочет удалить адрес? Удалить адрес в базе данных, а затем удалить его из списка? Или они просто делают все удаления / добавления, которые хотят, и я каждый раз выгружаю все из базы данных и обновляю все, что находится в коллекции Customer.Addresses? Какой правильный поток здесь?

Если коллекция адресов обновляется через репозиторий, вызывая что-то вроде этого: 

public void AddAddressToCustomer(Customer c, Address a)
{
    //validate and save address to db
    //add the newly saved address to the Customer Object
}

Помощь ...

Ответы [ 3 ]

3 голосов
/ 29 января 2009

DDD - это область, в которой у меня большой интерес, но мало опыта, поэтому, пожалуйста, отнеситесь к моим предложениям осторожно. Я предлагаю их только из-за отсутствия других, более авторитетных ответов.

В ' книге ' по адресу Эрика Эванса дается пример чего-то, что обычно следует рассматривать как Объект Значения, а не как сущность. Поэтому я считаю, что метод Add будет принадлежать Customer:

customer.Add (адрес);

Будет хранилище клиентов (но не одно для адресов). Это может быть использовано так:

customerRepository.Update (заказчик);

Преднамеренное влияние этого состоит в том, что все сложные вопросы, которые вы задаете о том, как это затем реализуется на уровне БД, не относятся к объектам домена (т.е. объекту заказчика). Боюсь, я не могу помочь после этого.

1 голос
/ 04 февраля 2009

Зависит от ответа. После добавления адреса к клиенту и сохранения клиента с помощью: 

customer.Add(address);
customerRepository.Update(customer);

После этого ваш репозиторий отобразит объектов вашего уровня клиента и адресного домена на LINQ to SQL. Это, вероятно, потребует создания нового объекта DataContext, получения связанных сущностей LINQ to SQL (или создания новых), а затем сопоставления сущностей уровня домена с вашими сущностями LINQ to SQL. 

var context = new MyDataContext();
var linqCustomer = MapCustomerToLinqCustomer(context, customer);
var linqAddress = MapAddressToLinqAddress(context, customer.Addresses.First());
context.SubmitChanges();

Вы также можете использовать классы DataMapper для отображения, но методы MapXYZ более точно следуют примеру Роба Конери. Если вам нужна дополнительная помощь с методами MapXYZ, дайте мне знать.

1 голос
/ 30 января 2009

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

...