ASP.NET MVC - 业务逻辑是否应该存在于控制器中？

Question

Derik Whitaker 发布了 文章 几天前，它触及了一些我一直好奇的点time：业务逻辑应该存在于控制器中吗？

到目前为止，我见过的所有 ASP.NET MVC 演示都将存储库访问和业务逻辑放在控制器中。 有些甚至还在那里进行验证。 这会导致控制器相当大、臃肿。 这真的是MVC框架的使用方式吗？ 看起来这最终会导致大量重复的代码和逻辑分布在不同的控制器上。

Answer 1

业务逻辑确实应该在模型中。 你应该瞄准胖模型、瘦控制器。

例如，不要有：

public interface IOrderService{
    int CalculateTotal(Order order);
}

我宁愿有：

public class Order{
    int CalculateTotal(ITaxService service){...}        
}

这假设税收是由外部服务计算的，并且要求您的模型了解外部服务的接口。

这会让你的控制器看起来像：

public class OrdersController{
    public OrdersController(ITaxService taxService, IOrdersRepository ordersRepository){...}

    public void Show(int id){
        ViewData["OrderTotal"] = ordersRepository.LoadOrder(id).CalculateTotal(taxService);
    }
}

或者类似的东西。

Answer 2

我喜欢 Microsoft Patterns & 提供的图表。 实践。 我相信“一图胜千言”这句格言。

Answer 3

这是一个令人着迷的问题。

我认为有趣的是，大量示例 MVC 应用程序实际上未能遵循 MVC 范例，即真正将“业务逻辑”完全放置在模型中。 Martin Fowler 指出，MVC 并不是四人帮意义上的模式。 相反，如果程序员要创建超出玩具应用程序的内容，则必须添加模式，这是范例。

因此，简短的回答是“业务逻辑”确实不应该存在于控制器中，因为控制器具有处理视图和用户交互的附加功能，并且我们希望创建仅具有一个目的的对象。

更长的答案是，在将逻辑从控制器移动到模型之前，您需要对模型层的设计进行一些思考。 也许您可以使用 REST 处理所有应用程序逻辑，在这种情况下，模型的设计应该相当清晰。 如果没有，您应该知道将使用什么方法来防止模型变得臃肿。

Answer 4

您可以查看 Stephen Walther 撰写的这个很棒的教程，其中显示 验证服务层。

了解如何移动验证
控制器操作的逻辑
并进入一个单独的服务层。 在
本教程，斯蒂芬·沃尔特
解释如何保持敏锐
通过隔离来分离关注点
您的服务层
控制器层。

Answer 5

业务逻辑不应包含在控制器中。 控制器应尽可能精简，最好遵循以下模式：

1. 查找域实体
2. 对域实体进行操作
3. 准备用于查看/返回结果的数据

另外，控制器可以包含一些应用程序逻辑。

那么我的业务逻辑应该放在哪里呢？ 在模型中。

什么是模型？ 这是一个好问题。 请参阅Microsoft 模式和实践文章（感谢 AlejandroR 的出色发现）。 这里有三类模型：

• 视图模型：这只是一个数据包，具有最少的逻辑（如果有的话）将数据从视图传递到视图，包含基本的字段验证。
• 域模型：具有业务逻辑的胖模型，对单个或多个数据实体进行操作（即给定状态下的实体A而不是对实体B的操作）
• 数据模型：存储-感知模型，单个实体中包含的逻辑仅与该实体相关（即，如果字段 a，则字段 b）。

当然，MVC 是一种有不同变体的范例。 我这里描述的是MVC仅占据顶层，参见维基百科上的这篇文章

如今，MVC 和类似的模型-视图-呈现器 (MVP) 是关注点分离设计模式，专门适用于较大系统的表示层。 在简单的场景中，MVC 可能代表系统的主要设计，直接进入数据库； 然而，在大多数情况下，MVC 中的控制器和模型对服务或数据层/层具有松散的依赖关系。 这都是关于客户端-服务器架构的

Answer 6

如果您使用依赖注入器，您的业务逻辑将转到它们，因此您将获得整洁干净的控制器。