我已经在.NET MVC3中工作了很多,在那里它是希望有一个贫血模型.查看模型和编辑模型最好是愚蠢的数据容器,您可以从控制器传递到视图.任何一种应用程序流都应该来自控制器,并且视图处理UI的问题.在MVC中,我们不想在模型中有任何行为.

但是我们也不希望控制器中有任何业务逻辑.对于更大的应用程序,最好保持域代码与模型,视图和控制器分离,并且独立于模型,视图和控制器(通常为HTTP).因此,有一个单独的项目,在任何其他之前提供域模型(实体和价值对象,根据DDD组成聚合).

我已经尝试从一个贫穷的模式中转移到一个更丰富的领域代码,我在想放弃.在我看来,像包含数据和行为的实体类违反了SRP.

以Web为例,一个非常常见的情况,撰写电子邮件.给定一些事件,给定一个EmailTemplate,EmailAddress和自定义值组成一个EmailMessage对象是域的责任.该模板作为具有属性的实体存在,并且自定义值作为用户的输入提供.我们还要说明的是,EmailMessage的FROM地址可以由外部服务(IConfigurationManager.DefaultFromMailAddress)提供.鉴于这些要求,似乎一个丰富的域名模型可以使EmailTemplate负责撰写EmailMessage：

public class EmailTemplate
{
    public EmailMessage ComposeMessageTo(EmailAddress to,IDictionary<string,string> customValues,IConfigurationManager config)
    {
        var emailMessage = new EmailMessage(); // internal constructor
                                            // extension method
        emailMessage.Body = this.BodyFormat.ApplyCustomValues(customValues);
        emailMessage.From = this.From ?? config.DefaultFromMailAddress;
        // bla bla bla
        return emailMessage;
    }
}

这是我在富域模式的尝试之一.添加此方法之后,EmailTemplate的责任在于包含实体数据属性和撰写邮件.大概15行长,似乎把课堂从真正意义上成为一个EmailTemplate分散了,而IMO,它只是存储数据(主题格式,正文格式,附件和可选的/回复地址) ).

我最终把这个方法重构成一个专门的课程,唯一的责任是组合一个EmailMessage给出以前的论据,而且我更开心了.事实上,我开始喜欢贫血的领域,因为它有助于我分开责任,使课堂和单元测试更短,更简洁,更集中.似乎使实体和其他数据对象“没有行为”可以很好地分离责任.还是我跟踪这里？