首先: 我相信您混淆了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.

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

域逻辑。 应用程序逻辑。

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

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

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

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

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

Q1:

业务逻辑可以分为两类:

域逻辑，如电子邮件地址上的控件(唯一性、约束等)，获取产品的发票价格，或者根据其产品对象计算购物车的总价。 更广泛和复杂的工作流被称为业务流程，例如控制学生的注册流程(通常包括几个步骤，需要不同的检查，有更复杂的约束)。

第一类属于模型，第二类属于控制器。这是因为第二类中的情况是广泛的应用程序逻辑，将它们放在模型中可能会混淆模型的抽象(例如，不清楚我们是否需要将这些决策放在一个模型类中还是另一个模型类中，因为它们与两者都相关!)

请看这个答案，了解模型和控制器之间的具体区别，这个链接有非常精确的定义，这个链接还有一个很好的Android示例。

重点是上面“Mud”和“Frank”提到的注释可能是正确的，“Pete”的注释也是正确的(根据业务逻辑的类型，业务逻辑可以放在模型或控制器中)。

最后，注意MVC因上下文而异。例如，在Android应用程序中，建议一些不同于基于web的定义(参见这篇文章的例子)。

Q2:

业务逻辑更一般，(正如上面提到的“反气旋”)它们之间的关系如下:

业务规则业务逻辑

Model =用于CRUD数据库操作的代码。

Controller =响应用户操作，并根据特定于组织的业务规则将用户的数据检索或删除/更新请求传递给模型。这些业务规则可以在助手类中实现，如果不是太复杂的话，也可以直接在控制器操作中实现。控制器最后要求视图更新自己，以便以新显示的形式给用户反馈，或者像'updated, thanks'之类的消息，

View =基于对模型的查询生成的UI。

关于业务规则应该放在哪里，没有硬性规定。在一些设计中，它们进入模型，而在另一些设计中，它们包含在控制器中。但我认为最好还是把它们放在控制器里。让模型只关心数据库连通性。

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

正如几个答案所指出的，我相信人们对多层架构和MVC架构有一些误解。

多层架构包括将你的应用程序分解成几层(例如，表示、业务逻辑、数据访问)

MVC是应用程序表示层的一种体系结构样式。对于重要的应用程序，业务逻辑/业务规则/数据访问不应该直接放在模型、视图或控制器中。这样做会将业务逻辑放在表示层，从而降低代码的重用性和可维护性。

该模型是放置业务逻辑的一个非常合理的选择，但更好/更可维护的方法是将表示层与业务逻辑层分离，并创建一个业务逻辑层，并在需要时从模型中调用业务逻辑层。业务逻辑层将依次调用数据访问层。

我想指出的是，在一个MVC组件中发现混合了业务逻辑和数据访问的代码并不少见，特别是在应用程序没有使用多层架构的情况下。然而，在大多数企业应用程序中，您通常会在表示层中发现带有MVC体系结构的多层体系结构。