A1:业务逻辑进入MVC的模型部分。Model的作用是包含数据和业务逻辑。另一方面，控制器负责接收用户输入并决定要做什么。

A2:业务规则是业务逻辑的一部分。他们有一种关系。业务逻辑具有业务规则。

看看维基百科中关于MVC的条目。转到概览，其中提到MVC模式的流程。

还可以查看维基百科中的Business Logic条目。上面提到，业务逻辑由业务规则和工作流组成。

业务规则在模型中。

假设您正在为邮件列表显示电子邮件。用户单击其中一封电子邮件旁边的“删除”按钮，控制器通知模型删除条目N，然后通知视图模型已更改。

也许管理员的电子邮件永远不应该从列表中删除。这是一个业务规则，该知识属于模型。视图最终可能以某种方式表示该规则——也许模型公开了一个“IsDeletable”属性，该属性是业务规则的一个功能，因此视图中的删除按钮对于某些条目是禁用的——但视图中不包含规则本身。

模型是数据的最终把关人。您应该能够在不接触UI的情况下测试业务逻辑。

将业务层放在MVC项目的模型中是没有意义的。

假如你的老板决定把演示层换成别的东西，你就完蛋了!业务层应该是一个单独的程序集。Model包含来自业务层的数据，这些数据传递给视图进行显示。然后在post中，例如，模型绑定到驻留在业务层的Person类，并调用PersonBusiness.SavePerson(p);其中p是Person类。以下是我所做的(BusinessError类没有，但也会在BusinessLayer中):

在我看来，业务逻辑这个术语并不是一个精确的定义。Evans在他的书《领域驱动设计》中谈到了两种类型的业务逻辑:

域逻辑。 应用程序逻辑。

在我看来，这种分离要清楚得多。在认识到有不同类型的业务规则的同时，也认识到它们不一定都去同一个地方。

域逻辑是对应于实际域的逻辑。因此，如果您正在创建一个会计应用程序，那么域规则将是关于帐户、发帖、税收等的规则。在一个敏捷的软件计划工具中，规则是像基于速度和backlog中的故事点计算发布日期之类的东西。

对于这两种类型的应用程序，CSV导入/导出可能是相关的，但CSV导入/导出的规则与实际域无关。这种逻辑就是应用逻辑。

领域逻辑肯定会进入模型层。该模型还对应于DDD中的领域层。

然而，应用程序逻辑并不一定要放在模型层中。这些规则可以直接放在控制器中，也可以创建一个单独的应用程序层来承载这些规则。在这种情况下，什么是最合乎逻辑的取决于实际的应用程序。

首先: 我相信您混淆了MVC模式和基于n层的设计原则。 使用MVC方法并不意味着不应该对应用程序进行分层。 如果您将MVC看作是表示层的扩展，这可能会有所帮助。 如果你把非表示代码放在MVC模式中，你可能很快就会得到一个复杂的设计。 因此，我建议您将业务逻辑放到单独的业务层中。

看看这个:维基百科上关于多层架构的文章 它说:

今天，MVC和类似的模型-视图-表示器(MVP)都是关注点分离设计模式，专门应用于大型系统的表示层。

Anyway ... when talking about an enterprise web application the calls from the UI to the business logic layer should be placed inside the (presentation) controller. That is because the controller actually handles the calls to a specific resource, queries the data by making calls to the business logic and links the data (model) to the appropriate view. Mud told you that the business rules go into the model. That is also true, but he mixed up the (presentation) model (the 'M' in MVC) and the data layer model of a tier-based application design. So it is valid to place your database related business rules in the model (data layer) of your application. But you should not place them in the model of your MVC-structured presentation layer as this only applies to a specific UI. This technique is independent of whether you use a domain driven design or a transaction script based approach. Let me visualize that for you:

表示层:模型-视图-控制器

业务层:领域逻辑——应用程序逻辑

数据层:数据存储库-数据访问层

The model that you see above means that you have an application that uses MVC, DDD and a database-independed data layer. This is a common approach to design a larger enterprise web application. But you can also shrink it down to use a simple non-DDD business layer (a business layer without domain logic) and a simple data layer that writes directly to a specific database. You could even drop the whole data-layer and access the database directly from the business layer, though I do not recommend it.

[Note:] You should also be aware of the fact that nowadays there is more than just one "model" in an application. Commonly, each layer of an application has it's own model. The model of the presentation layer is view specific but often independent of the used controls. The business layer can also have a model, called the "domain-model". This is typically the case when you decide to take a domain-driven approach. This "domain-model" contains of data as well as business logic (the main logic of your program) and is usually independent of the presentation layer. The presentation layer usually calls the business layer on a certain "event" (button pressed etc.) to read data from or write data to the data layer. The data layer might also have it's own model, which is typically database related. It often contains a set of entity classes as well as data-access-objects (DAOs).

问题是:这如何适合MVC概念?

Answer -> It doesn't! Well - it kinda does, but not completely.This is because MVC is an approach that was developed in the late 1970's for the Smalltalk-80 programming language. At that time GUIs and personal computers were quite uncommon and the world wide web was not even invented! Most of today's programming languages and IDEs were developed in the 1990s. At that time computers and user interfaces were completely different from those in the 1970s. You should keep that in mind when you talk about MVC. Martin Fowler has written a very good article about MVC, MVP and today's GUIs.

为什么不引入一个服务层呢?这样你的控制器就会精简，可读性更强，所有的控制器功能都是纯粹的动作。您可以根据需要在服务层中分解业务逻辑。代码可重用性很高。对模型和存储库没有影响。