Q1:

业务逻辑可以分为两类:

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

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

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

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

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

Q2:

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

业务规则业务逻辑

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

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

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

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

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

Q1:

业务逻辑可以分为两类:

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

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

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

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

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

Q2:

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

业务规则业务逻辑

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

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

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

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

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

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

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

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

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