MVC中的业务规则在哪里

Question

现在大家都在谈论MVC，我注意到业务规则没有得到解决。在三层架构的旧时代，业务规则处于中间层。他们在哪里落入新的MVC？

Answer 1

起初，我会说他们属于模型。 MVC Entry on Wikipedia似乎同意：“在MVC中，模型表示应用程序的信息（数据）和用于操纵数据的业务规则”。 毕竟，按照“业务规则”，我们指的是对应用程序涉及的域进行编码的功能算法和逻辑，而不是与输入/输出相关的逻辑。这些与业务相关的核心逻辑不会 - 也不应该 - 根据向用户显示的内容（这是View的领域）或用户输入（主要由控制器接收）进行更改。

根据我的经验，在软件开发过程中提出这样一个问题非常明显：我们发现了很多被某些人认为是“业务规则”的事情，但事实证明是另外一回事。如果它不是真正的商业规则，它可能不属于该模型。

Answer 2

来自维基Article引述：

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

Answer 3

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

OurApp.Web - Asp.net MVC项目
OurApp.Business - 业务层图书馆
OurApp.DataAccess - 数据层图书馆
OurApp.Entities - 基本上所有的 '模型' 的所有图层共享

Answer 4

业务规则总是存在于模型中。该模型是您可以用完全不同的用户界面重新使用的一点。该视图显然完全依赖于UI选择，控制器必须从模型中获取数据并告诉视图进行渲染。

将业务逻辑放入视图很糟糕，因为它将结构与演示文稿联系在一起。

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

Answer 5

你永远不会看到MVC地址“业务规则”的原因是，MVC大体上是一种演示模式。它着重于如何构建您的应用程序。例如，模型可以被认为是演示模型。您的应用程序的模型，视图然后呈现。

但是，为了创建演示文稿模型，您通常需要转到所有业务逻辑所在的域模型。在那个时候，MVC并不指定代码的物理位置。它在另一层？ MVC不关心。

Answer 6

你们错了控制器中的商业规则，而不是模型......

Answer 7

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

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

控制器仅仅是用于拍摄用户输入和请求，执行动作中/上的模型和映射管理器视图中演示层。控制器不仅仅是一个中介，视图OR控制器可能会对模型采取行动。

Answer 8

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

Answer 9

这是一个古老发布的问题，但我喜欢规则存储库以完全独立于应用程序的任何部分。多个应用程序（业务层的多个实现）应该能够访问业务规则库的静态呈现。简单的分离决定，例如这样就可以从桌面 - > web进行迁移，例如微不足道的。

在我的体系结构中，查看 - >模型 - >控制器 - >业务层 - >规则存储库，即控制器访问业务层/层提供的粗糙数据，将其提供给模型，形式，并且视图被动地显示它。业务层可以在任何表示格式中重复使用，将具有明确的规则并可以通过隐式规则访问子系统。按照设计，每个组件都不知道其上面组件的细节。