DDD,实体框架,聚合实体行为Person.AddEmail等

问题描述

| 这是我遇到的问题的一个简单示例,该问题与此处介绍的一些想法以及有关DDD的其他地方没有联系。 说我有一个创建/操纵一个人的ASP.NET MVC 3网站。控制器访问应用程序服务层(PersonService),后者又使用域实体(EF 4 POCO)和PersonRepository进行更改并保留它们。为了简单起见,我在这里省略了所有接口。在这种情况下,“人”是根,并且为简单起见,仅具有电子邮件地址(还假定电子邮件不是不可变的并且可以更新)。 选项1: 尝试坚持[我的理解] DDD的基础知识,在DDD的基础上,与实体直接相关的行为被实现为实体的一部分(Person实现AddEmail,ChangeEmail等)。唯一的问题是,除了Add *方法之外,人员将需要了解上下文或实体框架(这将消除任何持久性无知)或需要使用“服务”或存储库将电子邮件标记为已修改
// 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\'s 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: 让人员服务使用存储库添加/更新电子邮件地址,并且不要在人员实体上实现该行为。在多对多关系的情况下(例如,地址,需要更新两个表以完成工作),这要简单得多,但是模型变成“贫民窟”,只是一堆getter和setter。
// 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; }
}
无论如何,对此有何想法? 谢谢,Brian     

解决方法

        选择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-它很聪明,可以弄清楚自从上次Person保留以来发生了什么变化。很难说实体框架如何精确地处理这一问题。     ,        我是NH用户,可能不知道所有EF限制,但总的来说,无论ORM的限制如何,实体都应保持尽可能干净。服务层已经与数据访问结合在一起,因此不会造成任何危害。 而且我相信EF4应该知道如何跟踪馆藏变化。如果不是,那么最好的方法是将添加/删除逻辑保留在Person实体中,并保留在PersonService中。 顺便说一句,您的EmailAddress在这里不是实体,没有ID(我猜只是一个错字)。以及如何将您的EmailAddress链接到Person?