问“业务逻辑应该在服务中，而不是在模型中”有多准确？

EN

至于你的头衔，我认为这个问题没有道理。MVC模型由数据和业务逻辑组成。说逻辑应该在服务中，而不是在模型中，就像说，“乘客应该坐在座位上，而不是在车里”。

再说一遍，“模型”一词是一个过载的术语。您可能不是指MVC模型，而是指数据传输对象(，DTO)意义上的模型。也就是一个实体。这就是马丁·福勒说的。

在我看来，马丁·福勒( Martin )是在一个理想的世界里谈论事情。在Hibernate和JPA (在Java中)的现实世界中，DTO是一个超级泄漏的抽象。我想把我的业务逻辑放在我的实体里。会让事情变得更干净。问题是，这些实体可能存在于托管/缓存状态中，这种状态很难理解，并且经常阻止您的工作。总结一下我的观点: Martin推荐了正确的方法，但是ORMs阻止了你这样做。

我认为鲍勃马丁有一个更现实的建议和他在这段不免费的视频里给了它。他说要让你的DTO不受逻辑限制。他们只需保存数据并将其传输到另一个更面向对象的层，而不直接使用DTO。这样就避免了漏洞百出的抽象概念来咬你。DTO和DTO本身的层不是OO。但是一旦你走出了这一层，你就会像马丁·福勒所倡导的那样成为OO。

这种分离的好处是它抽象化了持久层。您可以从JPA切换到JDBC (反之亦然)，任何业务逻辑都不需要更改。它只是依赖于DTO，它不在乎这些DTO是如何填充的。

要稍微改变主题，您需要考虑SQL数据库不是面向对象的事实。但是ORMs通常每个表都有一个实体--即一个对象。所以从一开始你就已经输了一场仗。根据我的经验，您永远无法以面向对象的方式来表示实体。

至于“服务”，Bob将反对拥有一个名为FooBarService的类。那不是面向对象的。服务是做什么的？任何与FooBars相关的信息。它也可以被标记为FooBarUtils。我认为他会提倡一个服务层(更好的名称应该是业务逻辑层)，但是该层中的每个类都有一个有意义的名称。

我现在正在做绿地项目，昨天我们不得不做出一些建筑上的决定。有趣的是，我不得不重温“企业应用程序体系结构模式”的几个章节。

这就是我们想出来的：

• 数据层查询和更新数据库。该层通过可注入的存储库公开。
• 域层这就是业务逻辑存在的地方。该层使用了可注入的存储库，并负责大部分业务逻辑。这是我们将彻底测试的应用程序的核心。
• 服务层该层与域层对话，并为客户端请求提供服务。在我们的例子中，服务层非常简单--它将请求转发到域层，处理安全性和其他很少的横切关注点。这与MVC应用程序中的控制器没有多大不同--控制器又小又简单。
• 客户层。通过SOAP与服务层对话。

最后，我们得出以下结论：

Client ->服务->域->数据

我们可以用合理的工作量取代客户、服务或数据层。如果您的域逻辑存在于服务中，并且您已经决定要替换甚至删除服务层，那么您必须将所有业务逻辑移到其他地方。这样的要求很少见，但可能会发生。

说了这些之后，我认为这与马丁·福勒所说的非常接近。

这些服务位于域模型之上，并将域模型用于数据。

下图很好地说明了这一点：

http://martinfowler.com/eaaCatalog/serviceLayer.html

说明为什么程序员不愿将域逻辑放入域对象的最简单的方法是，他们通常面临“我将验证逻辑放在哪里？”的情况。以这个域对象为例：

public class MyEntity
{
    private int someProperty = 0;

    public int SomeProperty
    {
        get { return this.someProperty; }
        set
        {
            if(value < 0) throw new ArgumentOutOfRangeException("value");
            this.someProperty = value;
        }
    }
}

因此，我们在setter中有一些基本的验证逻辑(不能是否定的)。问题是你不能真正重复使用这个逻辑。在某个地方，屏幕、ViewModel或Controller需要在将更改提交到域对象之前进行验证，因为它需要在用户单击“保存”按钮之前或单击“保存”按钮时通知用户他们不能这样做，以及原因。调用setter时对异常进行测试是一种丑陋的攻击，因为您甚至应该在启动事务之前完成所有的验证。

这就是为什么人们会移动验证逻辑--某种服务，比如MyEntityValidator。然后，实体和调用逻辑都可以获得对验证服务的引用并重用它。

如果不这样做，并且仍然希望重用验证逻辑，则最终将其放入实体类的静态方法中：

public class MyEntity
{
    private int someProperty = 0;

    public int SomeProperty
    {
        get { return this.someProperty; }
        set
        {
            string message;
            if(!TryValidateSomeProperty(value, out message)) 
            {
                throw new ArgumentOutOfRangeException("value", message);
            }
            this.someProperty = value;
        }
    }

    public static bool TryValidateSomeProperty(int value, out string message)
    {
        if(value < 0)
        {
            message = "Some Property cannot be negative.";
            return false;
        }
        message = string.Empty;
        return true;
    }
}

这将使您的域模型更少“贫血”，并将验证逻辑保持在属性旁边，这很好，但我认为没有人真正喜欢静态方法。