现在人人都在谈论MVC，我注意到业务规则并没有得到关注。在旧的3层架构中，业务规则位于中间层。在新的MVC中它们属于哪一层？
MVC中的业务规则存储在哪里？
26
- Scott and the Dev Team
2
4那么？快速排序已经有46年历史了，但它仍然被广泛使用。重要的是它非常有效。 - Mauricio Scheffer
我几年前也注意到了同样的事情。似乎我一学会它，就开始到处出现了。 - Bill the Lizard
9个回答
39
你从来没有看到MVC涉及"业务规则"的原因是，MVC主要是一个表示层模式。它专注于如何组织应用程序。例如，可以将Model视为表示模型。你的应用程序模型，然后由View呈现。
然而，为了创建表示模型，通常需要访问包含所有业务逻辑的领域模型。此时，MVC并不指定代码物理位置。它是否位于另一个层中？MVC并不关心。
- Haacked
19
根据第一印象，我认为这些内容属于模型(Model)。维基百科上的MVC Entry也认同这个观点："在MVC中，模型代表应用程序的信息(数据)以及用于操作数据的业务规则"。毕竟，我们所说的“业务规则”是指编码应用程序所涉及领域的功能算法和逻辑，而不是与输入/输出相关的逻辑。这些核心与业务相关的逻辑不应该因为展示给用户的内容（这是视图(View)的领域）或用户输入（主要由控制器(Controller)接收）而改变。
根据我的经验，在软件开发过程中问这种问题非常有启发性：我们发现许多人认为是“业务规则”的东西实际上并不是。如果它不是真正的业务规则，那么它可能不属于模型。
- FOR
1
2模型不应该在MVC项目中，也不应该依赖于任何特定的UI技术。 - Andy
12
业务规则总是存在于模型中。模型是您可以在完全不同的UI上重用的部分。视图显然完全依赖于UI选择，控制器必须从模型中取数据并告诉视图进行渲染。
将业务逻辑放入视图中是不好的，因为它将结构与呈现绑定在一起。
将业务逻辑放入控制器中是不好的，因为它会将业务领域分成由模型持久化的数据和控制器的规则两部分。
- domgblackwell
5
一段来自维基百科文章的引用：
MVC通常出现在Web应用程序中，其中视图是实际的HTML页面，控制器是收集动态数据并生成HTML内容的代码。最后，模型由实际内容表示，通常存储在数据库或XML节点中，并且业务规则根据用户操作转换该内容。
MVC通常出现在Web应用程序中，其中视图是实际的HTML页面，控制器是收集动态数据并生成HTML内容的代码。最后，模型由实际内容表示，通常存储在数据库或XML节点中，并且业务规则根据用户操作转换该内容。
- gimel
1
那不是MVC。MVC是关于组织代码的。按照你的定义，所有动态网页都会是MVC。 - Bernard Igiri
4
你为什么不能混合使用MVC和N层架构？我们的应用程序就是这样做的。我们的控制器用于数据验证，并决定调用哪个业务层。
OurApp.Web - Asp.net MVC项目
OurApp.Business - 业务层库
OurApp.DataAccess - 数据层库
OurApp.Entities - 基本上是所有层共享的“模型”
- Vyrotek
1
2我喜欢这种方法。不幸的是，我认为许多Web框架使这种跳跃变得不舒服。在某些时候，您可能需要业务层中的辅助对象，这些对象不一定对应任何数据库表/持久存储 - 这似乎是每个模型类都认为是基础的事情。此时，您会想知道，我应该把这段代码放在哪里？ - Koobz
2
业务规则应该在模型中，而不是控制器中。控制器和视图属于表示层。
模型代表领域实体和功能。
控制器只是一个管理器，用于接受用户输入和请求，在模型中执行操作，并将其映射到表示层的视图上。控制器不仅仅是一个中介者，视图或控制器都可以对模型进行操作。
- Logic Labs
1
4许多人内在地认为模型是“数据库模型”，这就是为什么业务规则似乎没有位置。相反，如果您将模型视为对真实世界中某个事物的模拟，则显然业务规则与其操纵的数据一样是模型的一部分。 - Michael Dillon
1
这是一个古老的问题，但我喜欢规则存储库完全独立于应用程序的任何部分。多个应用程序，多个业务层实现，应该能够访问业务规则存储库的静态呈现。像这样的简单分离决策使得从桌面迁移到Web等变得微不足道。
在我的架构中，视图->模型->控制器->业务层->规则存储库，即控制器访问业务层/层呈现的粗略数据，将其提供给模型进行处理成可呈现的形式，而视图被动地显示它。业务层可以跨任何演示格式重复使用，并具有明确的规则和对具有隐含规则的子系统的访问权限。按设计，每个组件都不知道其上方组件的详细信息。
在我的架构中，视图->模型->控制器->业务层->规则存储库，即控制器访问业务层/层呈现的粗略数据，将其提供给模型进行处理成可呈现的形式，而视图被动地显示它。业务层可以跨任何演示格式重复使用，并具有明确的规则和对具有隐含规则的子系统的访问权限。按设计，每个组件都不知道其上方组件的详细信息。
- Jeff Dunlop
0
我认为问题在于定义的问题。在我看来，按照所需顺序呈现屏幕的逻辑是控制器问题，我见过一些项目使用规则引擎确定顺序和用户所需输入。这与业务规则不同，在我看来。
- John Caro
1
我相信OP在谈论属于模型的业务逻辑。 - Tae-Sung Shin
-7
你们错了，业务规则应该放在控制器而不是模型中...
- Annie
1
2这个评论是完全错误的。控制器是应用程序的技术部分，它编排数据流并在模型和视图中触发操作。在典型的PC应用程序中，控制器关注鼠标事件、按键和类似的事情。 - Michael Dillon
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接