Design patterns MVC中的业务逻辑

我有两个问题：

问题1。MVC模式中的“业务逻辑”到底在哪里？我对模型和控制器感到困惑

问题2。“业务逻辑”与“业务规则”相同吗？如果没有，有什么区别

---

如果你能用一个小例子来解释，那就太好了。

业务规则在模型中

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

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

---

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

A1：业务逻辑转到

MVC

中的

模型

部分。

模型的作用是包含数据和业务逻辑<另一方面，代码>控制器

负责接收用户输入并决定要做什么

A2：

业务规则

是

业务逻辑

的一部分。它们之间有

关系<代码>业务逻辑

具有

业务规则

看一看。转到概述，其中提到了

MVC

模式的流程

---

再看看。需要指出的是，

业务逻辑

由

业务规则

和

工作流

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

• 域逻辑
• 应用程序逻辑

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

域逻辑是与实际域相对应的逻辑。因此，如果您正在创建一个会计应用程序，那么域规则将是关于帐户、过账、税务等的规则。在敏捷软件规划工具中，这些规则将是基于速度和待办事项中的故事点计算发布日期等

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

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

---

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

模型=CRUD数据库操作代码

Controller=响应用户操作，并根据特定于组织的业务规则，将数据检索或删除/更新的用户请求传递给模型。这些业务规则可以在助手类中实现，或者如果它们不太复杂，则直接在控制器操作中实现。控制器最后要求视图更新自身，以便以新显示或“更新，谢谢”等消息的形式向用户提供反馈

视图=根据模型上的查询生成的UI

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

首先：
我相信您将MVC模式和基于n层的设计原则混为一谈。

使用MVC方法并不意味着不应该分层应用程序。
如果您认为MVC更像是表示层的扩展，这可能会有所帮助。

如果将非表示代码放入MVC模式中，可能很快就会陷入复杂的设计中。
因此，我建议您将业务逻辑放在单独的业务层中。

看看这个：

它说：

如今，MVC和类似的模型视图演示器（MVP）是一种分离关注点的设计模式，专门应用于大型系统的表示层

无论如何。。。当谈论企业web应用程序时从UI到业务逻辑层的调用应该放在（表示）控制器内部。

这是因为控制器实际上处理对特定资源的调用，通过调用业务逻辑查询数据，并将数据（模型）链接到适当的视图。

Mud告诉过您，业务规则将进入模型。
这也是事实，但他混淆了（表示）模型（MVC中的“M”）和基于层的应用程序设计的数据层模型。
因此，在应用程序的模型（数据层）中放置与数据库相关的业务规则是有效的。
但是您不应该将它们放在MVC结构化表示层的模型中，因为这只适用于特定的UI。

此技术与您使用的是域驱动设计还是基于事务脚本的方法无关。

让我为您设想一下：

---

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

---

业务层：域逻辑-应用程序逻辑

---

数据层：数据存储库-数据