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

Question

这是一个我正在遇到的问题的一个简单例子,它没有与这里提出的一些想法和其他有关DDD的地方相关联.

假设我有一个ASP.NET MVC 3站点,可以创建/操作一个人.控制器访问应用程序服务层(PersonService),后者又使用域实体(EF 4 POCO)和PersonRepository进行更改并保留它们.为简单起见,我在这里省略了所有接口.在这种情况下,Person是根,为简单起见,只有电子邮件地址(也假设电子邮件不是不可变的,可以更新).

选项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'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

Answer 1

我是 NH 用户，可能不知道 EF 的所有限制，但一般来说，无论 ORM 有什么限制，实体都应该尽可能保持干净。服务层已经与数据访问结合在一起，因此不会造成任何损害。

我相信 EF4 应该知道如何跟踪集合更改。如果没有，那么最好的方法是将添加/删除逻辑保留在 Person 实体中并保留在 PersonService 中。

顺便说一句，您的电子邮件地址在这里不是一个实体，没有 ID（我猜只是一个拼写错误）。如何将您的电子邮件地址链接到人员？