3

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

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

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

哪个最好？如果 3 是最好的，那是不是存在循环依赖（因为我的模型项目依赖于服务项目，而服务项目又依赖于模型项目）？

4

5 回答 5

3

4 号是正确的方法。

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

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

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

于 2013-02-18T02:42:42.377 回答
3

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

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

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

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

我会断言，包含自省其自身属性并且不依赖于其他模型对象的消息和/或属性的方法的模型对象是良好的对象设计和 MVC 环境中的良好建模方法。

更新我与一位同事就此进行了讨论，他向我指出了贫血域模型，这是 Martin Fowler 的一篇优秀文章。在我的同事推荐后，我将这篇文章读了好几遍。

Fowler 先生文章的最后一段（这是来自 martinfowler.com 的直接引述，并承认并给予该网站的信用）：

“一般来说，你在服务中发现的行为越多，你就越有可能剥夺自己从领域模型中获得的好处。如果你所有的逻辑都在服务中，那么你就是在偷盲自己。”

于 2013-02-18T02:48:05.290 回答
0

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

于 2013-02-18T02:49:54.663 回答
0

通常我对模型而不是在模型中执行操作，但这是个人喜好。我会（在你的情况下）在服务层中编写逻辑，然后从控制器进行协调调用，该调用将在模型上运行。尽管如此，我相信有些人将此称为贫血域模型。

我认为任何方法都没有错，但我个人会选择 4 号。

于 2013-02-18T02:53:53.597 回答
0

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

选项 1 或选项 4 是否正确取决于您询问的对象。

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

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

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

将这样的东西移动到服务层会导致贫血域模型，您的模型类最终只是 dto 的

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

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

于 2013-02-18T10:42:02.423 回答