业务逻辑应该在模型中吗？ （MVC4）

Question

我的MVC应用程序中有一个名为“Stores”的类，它有一个名为“IsInCompliance”的类，它取决于其他几个字段的值。逻辑将通过并说“如果这个，这个，这是真的，那么IsInCompliance是真的”。

这应该属于模型定义，还是将此逻辑更好地放在服务层或控制器中？我想我有四个选择：

1. 模型中方法中包含的逻辑
2. 包含在写回模型的控制器中的逻辑
3. 模型调用的服务中包含的逻辑
4. 控制器调用的服务中包含的逻辑

哪个最好？如果3是最好的，那里是否存在循环依赖（因为我的模型项目依赖于服务项目，这取决于模型项目）？

Answer 1

4号是正确的方法。

控制器应该充当一个瘦的“流量控制”层，并将所有逻辑委托给它们下面的服务层（或者如果它不是太明显的逻辑，那么就是业务层 - 但这是一个不同的架构问题）。

您的模型通常应该是纯粹的POCO结构，可选择数据模型内部的微观逻辑。例如，ID生成和数据完整性操作。

您的大多数逻辑（对于相对简单/基于CRUD的应用程序）通常应驻留在服务层中。

Answer 2

这是一个偏好/风格问题，但我一直认为与Model对象密切相关的方法属于该对象。

以此为例（我在没有开放VS.NET实例的情况下即时编码，所以请原谅任何语法错误，只是尝试将其用作通信工具）：

public class Person 
{
    public Int32 Age { get; set; }

    public bool IsEligibleToEnterLegallyBindingContract() 
    {
        return Age >= 18;
    }
 }

我认为一个模型对象包含对其自身属性进行内省并且不依赖于其他模型对象的消息和/或属性的方法，这是良好的对象设计和MVC环境中的良好建模方法。

更新我与同事就此进行了讨论，他向我指出了Anemic Domain Model，这是Martin Fowler写的一篇优秀文章。在我的同事推荐之后，我多次阅读这篇文章。

Fowler先生的文章中的结尾段落（这是来自martinfowler.com的直接引用，并且信用被承认并提供给该网站）：

“一般来说，您在服务中发现的行为越多，您就越有可能抢夺域模型的好处。如果您的所有逻辑都在服务中，那么您就会失明。“

Answer 3

MVC就是分离问题。保持这种方式。通过将业务逻辑放在单独的类（层）中，将逻辑与数据分开。

Answer 4

通常我会对模型执行操作而不是模型中的操作，但这是个人偏好。 我会（在你的情况下）在服务层中编写逻辑，然后从控制器调用可以在模型上工作的协调调用。 但是，我认为有些人将此称为Anemic Domain Model。

我认为任何方法都不对，但我个人会选择4号。

Answer 5

我想这取决于你的编码风格。

选项1或选项4都是正确的，具体取决于您的要求。

对于这样的事情，我认为选项1是正确的。

如果IsInCompliance仅依赖于模型中其他属性的值，那么它应该在模型中。

如果IsInCompliance的值依赖于其他类，那么它应该在服务层中。

将这样的内容移动到服务层会产生一个Anemic Domain模型，其中您的模型类最终只是dto的

在面向对象的设计中，这被认为是反模式。

仍然有很多东西需要在服务层中，我只是不认为这是其中之一。