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?