现在每个人都在谈论MVC，我注意到业务规则没有得到解决。在3层架构的旧时代，业务规则处于中间层。它们属于新的MVC？
答案 0 :(得分：39)
你永远不会看到MVC地址“业务规则”的原因是MVC基本上是一种表示模式。它专注于如何构建您的应用程序。例如，模型可以被认为是表示模型。应用程序的模型，然后呈现视图。
但是，为了创建演示模型，您通常需要转到所有业务逻辑所在的域模型。那时，MVC没有规定代码在物理上存在的位置。它在另一层吗？ MVC并不关心。
答案 1 :(得分：18)
第一次刷，我会说他们属于模特。 MVC Entry on Wikipedia似乎同意：“在MVC中，模型代表应用程序的信息（数据）和用于操纵数据的业务规则”。 毕竟，“业务规则”是指编码应用程序所涉及的域的功能算法和逻辑，而不是输入/输出相关逻辑。这些核心业务相关逻辑不会 - 或者不应 - 根据向用户显示的内容（视图的域）或用户输入（主要由Controller接收）进行更改。
根据我的经验，在软件开发过程中提出这样的问题已经非常明显：我们发现很多东西被某些人视为“业务规则”，但结果却是其他东西。如果它不是真正的业务规则，则可能不属于该模型。
答案 2 :(得分：12)
业务规则始终存在于模型中。该模型是您可以使用完全不同的UI重新使用的模型。该视图显然完全依赖于UI选择，并且控制器必须从模型中获取数据并告诉视图呈现它。
将业务逻辑放入视图中是不好的，因为它将结构与表示联系起来。
将业务逻辑放入控制器是不好的，因为它会在模型持久保存的数据和控制器中的规则之间拆分业务域。
答案 3 :(得分：5)
来自维基百科的引用Article：
MVC经常出现在Web应用程序中，其中视图是实际的HTML页面，控制器是收集动态数据并在HTML中生成内容的代码。最后，模型由实际内容表示，通常存储在数据库或XML节点中，和业务规则根据用户操作转换内容。
答案 4 :(得分：4)
你有什么理由不能混合MVC和Ntier吗？我们的应用就是这样做的。我们的控制器用于数据验证，并决定要进行哪些业务层调用。
OurApp.Web - Asp.net MVC项目
OurApp.Business - 商业图书馆
OurApp.DataAccess - 数据层库
OurApp.Entities - 基本上所有图层共享的所有“模型”
答案 5 :(得分：2)
业务规则应该在模型中，而不是控制器。控制器和视图是表示层的一部分。
该模型代表域的实体和功能..
控制器仅仅是用于获取用户输入和请求，在模型中/上执行动作以及将其映射到表示层中的视图的管理器。控制器不仅仅是一个中介，视图或控制器可以作用于模型。
答案 6 :(得分：1)
这是一个古老的问题，但我喜欢规则库，完全独立于应用程序的任何部分。多个应用程序，业务层的多个实现，应该能够访问业务规则存储库的静态呈现。像这样的简单分离决策可以从桌面进行迁移 - ＆gt;例如，网络，琐碎。
在我的架构中，查看 - ＆gt;型号 - ＆gt;控制器 - ＆gt;业务层 - ＆gt;规则存储库，即控制器访问业务层/层所呈现的粗略数据，将其提供给模型，该模型将其按压成可呈现的形式，并且视图被动地显示它。可在任何表示格式中重复使用的业务层将具有明确的规则和对具有隐式规则的子系统的访问。按照设计，每个组件都不了解其上方组件的细节。
答案 7 :(得分：0)
我认为问题是定义问题。在我看来，按顺序显示屏幕的逻辑是控制器问题，我看到一些项目使用规则引擎来确定订单以及用户需要输入的内容。这与业务规则imho不同。
答案 8 :(得分：-6)
你们错误的是控制器内部的业务规则存在而不是模型......