ASP.NET MVC-控制器中是否应该存在业务逻辑？
Answers:
业务逻辑实际上应该在模型中。您应该针对胖模型，瘦控制器。
例如，与其具有：
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);
}
}
或类似的东西。
我喜欢Microsoft模式与实践提供的图表。我相信这句格言：“一张图片值得一千个单词”。
这是一个有趣的问题。
我认为很有趣的是，从真正将“业务逻辑”完全置于模型中的意义上讲，大量示例MVC应用程序实际上未能遵循MVC范例。马丁·福勒（Martin Fowler）指出，就“四人帮”而言，MVC并不是一种模式。相反，如果程序员正在创建超出玩具应用程序的内容，则必须向其添加模式，这是一种范例。
因此，简短的答案是“业务逻辑”确实不应该存在于控制器中，因为控制器具有处理视图和用户交互的附加功能，并且我们只希望创建一个目的的对象。
更长的答案是，您需要在将逻辑从控制器转移到模型之前，对模型层的设计进行一些思考。也许您可以使用REST处理所有应用程序逻辑，在这种情况下，模型的设计应该非常清晰。如果不是这样，您应该知道将使用什么方法来防止模型过大。
您可以查看Stephen Walther撰写的这篇很棒的教程，其中显示了“使用服务层进行验证”。
了解如何将验证逻辑从控制器操作中移出并移到单独的服务层中。在本教程中，Stephen Walther解释了如何通过将服务层与控制器层隔离来保持关注点的清晰分离。
控制器中不应包含业务逻辑。控制器应该尽可能的瘦，最好遵循模式：
- 查找域实体
- 对领域实体采取行动
- 准备数据以查看/返回结果
另外，控制器可以包含一些应用程序逻辑。
那么我该把业务逻辑放在哪里？在模型中。
什么是型号？现在，这是一个好问题。请参阅“ Microsoft模式和实践”文章（对AlejandroR的出色发现表示赞赏）。这里有三类模型：
- 视图模型：这只是一个数据包，具有最少的逻辑（如果有的话）将数据从视图传递到视图，并包含基本的字段验证。
- 域模型：具有业务逻辑的胖模型，对单个或多个数据实体（即，给定状态下的实体A而不是对实体B的操作）进行操作
- 数据模型：感知存储的模型，单个实体中包含的逻辑仅与该实体有关（即，如果字段a则字段b）
当然，MVC是一个范式，有多种形式。我在这里描述的只是MVC占据顶层，请参阅Wikipedia上的本文。
如今，MVC和类似的模型视图演示者（MVP）是“关注分离”设计模式，这些设计模式仅适用于大型系统的表示层。在简单的场景中，MVC可以代表系统的主要设计，直接进入数据库。但是，在大多数情况下，MVC中的Controller和Model对Service或Data层/层具有宽松的依赖关系。这一切都与客户端-服务器架构有关