"富域模型"能否违反单一责任原则？

Question

刚刚输入这个问题时出现了一个有趣的线索.我不认为它回答了我的问题.

我一直在使用.NET MVC3,在那里需要一个贫血的模型.查看模型和编辑模型最好是作为可以从控制器传递到视图的哑数据容器.任何类型的应用程序流都应来自控制器,并且视图处理UI问题.在MVC中,我们不希望模型中有任何行为.

但是,我们也不希望控制器中有任何业务逻辑.对于较大的应用程序的最好保持域代码单独的和独立的模型,视图和控制器(和HTTP一般为此事).因此,有一个单独的项目提供,任何事情之前,领域模型(以实体和值对象,根据DDD组合成聚集).

我做了一些尝试从一个贫血模型对域代码更丰富的一个,离开,我想放弃.在我看来,包含数据和行为的实体类都违反了SRP.

以网络上的一个非常常见的场景为例,撰写电子邮件.鉴于某些事件,在给定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,我对此感到非常高兴.事实上,我开始偏爱贫血领域,因为它帮助我将责任分开,使课程和单元测试更短,更简洁,更专注.似乎使实体和其他数据对象"没有行为"可能有助于分离责任.还是我在这里偏离轨道？

Answer 1

支持富域模型而不是贫血模型的论据取决于OOP的价值主张之一,即将行为和数据保持在彼此旁边.封装和内聚的核心好处是有助于推理代码.富域模型也可以被视为信息专家模式的实例.然而,所有这些模式的价值在很大程度上是主观的.如果您将数据和行为分开来更有帮助,那么就这样吧,尽管您也可能会考虑其他人来查看代码.我更愿意尽可能地封装.在这种情况下,更丰富的域模型的另一个好处是可以将某些属性设为私有.如果某个属性仅在该类中使用一种方法,为什么要将其公开？

富域模型是否违反SRP取决于您对责任的定义.根据SRP,责任是改变的一个原因,它本身需要一个定义.该定义通常取决于手头的用例.您可以声明模板类的职责是模板,其中包含所有影响,其中之一是从模板生成消息.其中一个模板属性的更改可能会影响该ComposeMessageTo方法,这表明这些可能是一个单一的责任.而且,该ComposeMessageTo方法是模板中最有趣的部分.模板的客户端不关心方法的实现方式或模板类的属性.他们只想根据模板生成消息.这也赞成将数据保存在该方法旁边.