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

Question

几天前，Derik Whitaker发表了一篇文章，达到了我一直以来很好奇的一点：控制器中是否应该存在业务逻辑？

到目前为止，我见过的所有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

您可以查看Stephen Walther撰写的这篇很棒的教程，其中显示了“使用服务层进行验证”。了解如何将验证逻辑从控制器操作中移出并移到单独的服务层中。在本教程中，Stephen Walther解释了如何通过将服务层与控制器层隔离来保持关注点的清晰分离。

Answer 3

控制器中不应包含业务逻辑。控制器应该尽可能的瘦，最好遵循模式：查找域实体对领域实体采取行动准备数据以查看/返回结果另外，控制器可以包含一些应用程序逻辑。那么我该把业务逻辑放在哪里？在模型中。什么是型号？现在，这是一个好问题。请参阅Microsoft模式和实践文章（对AlejandroR的出色发现表示赞赏）。这里有三类模型：视图模型：这只是一个数据包，具有最少的（如果有的话）逻辑来往于视图之间传递数据，其中包含基本的字段验证。域模型：具有业务逻辑的胖模型，对单个或多个数据实体（即，给定状态下的实体A而不是对实体B的操作）进行操作数据模型：感知存储的模型，单个实体中包含的逻辑仅与该实体相关（即，如果字段a则字段b）当然，MVC是一个范式，有多种形式。我在这里描述的只是MVC占据顶层，请参阅Wikipedia上的本文。如今，MVC和类似的模型视图演示者（MVP）是“关注分离”设计模式，这些设计模式仅适用于较大系统的表示层。在简单的场景中，MVC可以代表系统的主要设计，直接进入数据库。但是，在大多数情况下，MVC中的Controller和Model对Service或Data层/层具有宽松的依赖关系。这一切都与客户端-服务器架构有关