asp.net-mvc - MVC 中的业务规则在哪里

Question

现在每个人都在谈论 MVC，我注意到业务规则没有得到解决。在过去的 3 层架构中，业务规则位于中间层。它们在新的 MVC 中处于什么位置？

score 39 · Accepted Answer

您从未看到 MVC 地址“业务规则”的原因是 MVC 总的来说是一种表示模式。它专注于如何构建您的应用程序。例如，模型可以被认为是一个表示模型。应用程序的模型，然后视图呈现。

但是，为了创建表示模型，您通常需要转到所有业务逻辑所在的域模型。那时，MVC 并没有规定该代码的物理位置。是在另一层吗？MVC 不在乎。

score 18 · Accepted Answer

乍一看，我会说它们属于模型。维基百科上的MVC 条目似乎同意：“在 MVC 中，模型表示应用程序的信息（数据）和用于操作数据的业务规则”。毕竟，“业务规则”是指对应用程序所涉及的域进行编码的功能算法和逻辑，而不是与输入/输出相关的逻辑。这些与业务相关的核心逻辑不会或不应该根据向用户显示的内容（即视图的域）或用户输入（主要由控制器接收）而改变。

根据我的经验，在软件开发过程中提出这样的问题非常具有启发性：我们发现了大量被某些人认为是“业务规则”的东西，但结果却是另外一回事。如果它不是真正的业务规则，它可能不属于模型。

score 12 · Accepted Answer

业务规则始终存在于模型中。该模型是您可以通过完全不同的 UI 重复使用的部分。视图显然完全依赖于 UI 选择，控制器必须从模型中获取数据并告诉视图渲染它。

将业务逻辑放入视图是不好的，因为它将结构与表示联系在一起。

将业务逻辑放入控制器是不好的，因为它在模型持久化的数据和控制器中的规则之间分割了您的业务域。

score 5 · Accepted Answer

维基百科文章的引述：

MVC 经常出现在 Web 应用程序中，其中视图是实际的 HTML 页面，控制器是收集动态数据并在 HTML 中生成内容的代码。最后，模型由通常存储在数据库或 XML 节点中的实际内容以及基于用户操作转换该内容的业务规则来表示。

score 4 · Accepted Answer

有什么理由不能混合 MVC 和 Ntier 吗？我们的应用程序就是这样做的。我们的控制器用于数据验证并决定调用哪个业务层。

OurApp.Web - Asp.net MVC 项目
OurApp.Business - 业务层库
OurApp.DataAccess - 数据层库
OurApp.Entities - 基本上所有层共享的所有“模型”

score 2 · Accepted Answer

业务规则应该在模型中，而不是控制器中。控制器和视图是表示层的一部分。

该模型表示域的实体和功能..

控制器只是一个管理器，用于接受用户输入和请求，在模型中/模型上执行操作并将其映射到表示层中的视图。控制器也不仅仅是一个中介，视图或控制器可以作用于模型。

score 1 · Accepted Answer

这是一个古老的问题，但我喜欢规则存储库完全独立于应用程序的任何部分。多个应用程序、业务层的多个实现应该能够访问业务规则存储库的静态呈现。诸如此类的简单分离决策使得从桌面 -> Web 的迁移变得微不足道。

在我的架构中，视图 -> 模型 -> 控制器 -> 业务层 -> 规则存储库，即控制器访问业务层/层呈现的粗略数据，将其提供给模型，模型将其按摩成可呈现的形式，然后view 被动地显示它。可跨任何表示格式重用的业务层将具有显式规则，并且可以访问具有隐式规则的子系统。按照设计，每个组件都不知道它上面的组件的细节。

score 0 · Accepted Answer

我认为这个问题是一个定义问题。在我看来，按所需顺序呈现屏幕的逻辑是控制器问题，我已经看到一些项目使用规则引擎来确定顺序以及用户需要输入的内容。这与恕我直言的业务规则不同。

score -7 · Accepted Answer

-7

你们错了，业务规则存在于控制器而不是模型中......

于 2009-06-23T14:48:59.187 回答

asp.net-mvc - MVC 中的业务规则在哪里

9 回答 9

Related

Reference