DDD, Entity Framework, Совокупное поведение сущностей (Person.AddEmail и т.д.)
Вот простой пример проблемы, с которой я сталкиваюсь, не связан с некоторыми из представленных здесь идей и других мест, касающихся DDD.
Скажем, у меня есть сайт ASP.NET MVC 3, который создает/манипулирует человеком. Контроллеры получают доступ к слою службы приложений (PersonService), который, в свою очередь, использует объекты домена (EF 4 POCO) и PersonRepository для внесения изменений и их сохранения. Для удобства я оставляю здесь все интерфейсы. В этом случае человек является корнем, и для простоты есть только адреса электронной почты (также предполагается, что электронная почта не является неизменной и может быть обновлена).
Вариант 1:
Попытайтесь придерживаться [моего понимания] основ DDD, где поведение, непосредственно связанное с сущностью, реализовано как часть объекта (Person реализует AddEmail, ChangeEmail и т.д.). Единственная проблема с этим, за исключением методов Add *, заключается в том, что Person должен знать о деталях фреймворка контекста или сущности (что бы устранить любое незнание персистенции) или нужно использовать "службу" или репозиторий для отметки электронное письмо с изменениями.
// Person Service
public class PersonService {
// constructor injection to get unit of work and person repository...
// ...methods to add/update a person
public EmailAddress AddEmailAddress(int personId, EmailAddress email)
{
Person p = personRepository.Find(p => p.Id == personId).First();
p.AddEmail(email);
uow.SaveChanges();
return email;
}
public EmailAddress ChangeEmailAddress(EmailAddress email)
{
Person p = personRepository.Find(p => p.Id == personId).First();
p.ChangeEmail(email);
// change state of email object here so it updated in the next line???
// if not here, wouldn't the Person entity have to know about the context
// or use a service?
uow.SaveChanges();
return email;
}
}
// Person Repository
public class PersonRepository
{
// generic repository implementation
}
// Person Entity
public class Person
{
public string Name { get;set; }
public IEnumerable<EmailAddress> EmailAddresses { get;set; }
public void AddEmail(EmailAddress email)
{
this.EmailAddresses.Add(email);
}
public void ChangeEmail(EmailAddress email)
{
EmailAddress orig = this.EmailAddresses.First(e => e.Id == email.id);
// update properties on orig
// NOW WHAT? [this] knows nothing about the context in order to change state,
etc, or do anything to mark the email add updated
}
}
// Email
public class EmailAddress
{
public string Email { get;set; }
public bool IsPrimary { get;set; }
}
Вариант 2:
Позвольте службе лица использовать репозиторий для добавления/обновления адреса электронной почты и не выполнять поведение в человеческом сущности. Это намного проще в случае отношений многих или многих (например, адрес, где две таблицы необходимо обновить для завершения работы), но затем модель становится "анемией", являющейся просто связкой геттеров и сеттеров.
// Person Service
public class PersonService {
// constructor injection to get unit of work and person repository...
// ...methods to add/update a person
public EmailAddress AddEmailAddress(int personId, EmailAddress email)
{
Person p = personRepository.Find(p => p.Id == personId).First();
personRepository.AddEmail(personId, email);
uow.SaveChanges();
return email;
}
public EmailAddress ChangeEmailAddress(EmailAddress email)
{
personRepository.ChangeEmail(email);
uow.SaveChanges();
return email;
}
}
// Person Repository
public class PersonRepository
{
// generic repository implementation
}
// Person Entity
public class Person
{
public string Name { get;set; }
public IEnumerable<EmailAddress> EmailAddresses { get;set; }
}
// Email
public class EmailAddress
{
public string Email { get;set; }
public bool IsPrimary { get;set; }
}
В любом случае, какие-то мысли по этому поводу?
Спасибо, Брайан
Ответы
Ответ 1
Вариант 1 - путь.
Рассуждение простое - изменение адресов электронной почты вызывает проблемы с доменом. Бьюсь об заклад, ваши эксперты в области говорят, что им нужно будет изменить электронную почту. Это автоматически заменяет логическую логику логической логики как бизнес-логику, которая должна жить в модели домена. Объекты в основном определяются их поведением, а не данными, которые они хранят.
Также - подумайте дважды, прежде чем вы решите использовать единицу шаблона работы и обернуть все в сервисах. Совокупные корни предполагают использовать границы транзакций, и службы обычно бесполезны, если они просто завершают репозиторий и вызовы объектов домена.
У меня было бы что-то вроде этого:
public class Person{
public Email Email{get;private set;}
public void SpecifyEmail(Email email){
//some validation, if necessary
EnsureEmailCanBeChanged();
//applying state changes
Email=email;
//raising event, if necessary
Raise(new EmailChanged(this));
}
public class EmailChanged:Event<Person>{
public EmailChanged(Person p):base(p){}
}
}
public class Email{
public Email(string email){
//validations (e.g. email format)
Value=email;
}
//implicit to string, explicit from string conversions
}
public class PersonController{
public ActionResult SpecifyEmail(int person, string email){
_persons.Get(person).SpecifyEmail((Email)email);
return RedirectToAction("Person",new{person});
}
}
Я использую NHibernate - он достаточно умен, чтобы понять, что изменилось с тех пор, как в последний раз персонаж сохранялся. Трудно сказать, как именно сущность Framework обрабатывает это.
Ответ 2
Я являюсь пользователем NH и, возможно, не знаю всех ограничений EF, но, вообще говоря, независимо от ограничений ORM, объекты должны быть как можно более чистыми. Уровень сервиса уже связан с доступом к данным, поэтому никакого вреда не было.
И я считаю, что EF4 должен знать, как отслеживать изменения коллекции. Если нет, тогда лучший способ - оставить логику добавления/удаления в вашем объекте Person и сохраняться в PersonService.
Кстати, ваш EmailAddress не является сущностью здесь, без Id (просто опечатка, я думаю). И как вы связываете свой EmailAddress с Person?