Derik Whitaker 几天前发布了一个 article，这引起了我一段时间以来的好奇：控制器中应该存在业务逻辑吗？
到目前为止，我看到的所有 ASP.NET MVC 演示都将存储库访问和业务逻辑放在控制器中。有些甚至还会在那里进行验证。这导致了相当大、臃肿的控制器。这真的是使用MVC框架的方式吗？看起来这最终会导致大量重复的代码和逻辑分布在不同的控制器上。
【问题讨论】：
标签： asp.net-mvc design-patterns controller business-logic
我喜欢Microsoft Patterns & Practices 提供的图表。而且我相信这句格言“一张图胜过千言万语”。
【讨论】：
如果您使用依赖注入器，您的业务逻辑将转到它们，因此您将获得整洁干净的控制器。
【讨论】：
业务逻辑不应包含在控制器中。控制器应该尽可能瘦，最好遵循模式：
另外，控制器可以包含一些应用程序逻辑。
那么我应该把我的业务逻辑放在哪里呢？在模型中。
什么是模型？这是一个很好的问题。请参阅Microsoft Patterns and Practices article（感谢 AlejandroR 的出色发现）。这里有三类模型：
当然，MVC 是一种不同类型的范例。我这里描述的是 MVC 只占用顶层，视频this article on Wikipedia
今天，MVC 和类似的模型-视图-展示器 (MVP) 是关注点分离设计模式，专门应用于更大系统的表示层。在简单的场景中，MVC 可能代表系统的主要设计，直接进入数据库；然而，在大多数情况下，MVC 中的控制器和模型对服务或数据层/层都有松散的依赖关系。这是关于客户端-服务器架构的全部内容
【讨论】：
您可以查看显示 Validating with a Service Layer 的 Stephen Walther 的这个很棒的教程。
了解如何移动验证 控制器动作的逻辑 并进入一个单独的服务层。在 本教程，斯蒂芬·瓦尔特 解释了如何保持锋利 通过隔离来分离关注点 您的服务层来自您的 控制器层。
【讨论】：
这是一个有趣的问题。
我认为有趣的是，大量示例 MVC 应用程序实际上未能遵循 MVC 范式，即真正将“业务逻辑”完全置于模型中。 Martin Fowler 指出，MVC 不是四人组意义上的模式。相反，如果程序员要创建超出玩具应用程序的东西，则必须将模式添加到 是一种范式。
所以，简短的回答是“业务逻辑”确实不应该存在于控制器中，因为控制器具有处理视图和用户交互的附加功能，而我们希望创建只有一个目的的对象。
一个更长的答案是，在将逻辑从控制器移动到模型之前，您需要对模型层的设计进行一些思考。也许您可以使用 REST 处理所有应用程序逻辑，在这种情况下，模型的设计应该相当清晰。如果没有，你应该知道你将使用什么方法来防止你的模型变得臃肿。
【讨论】：
业务逻辑确实应该在模型中。你应该瞄准胖模型，瘦控制器。
例如，而不是：
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);
}
}
或者类似的东西。
【讨论】：