MVC 中的业务规则在哪里
现在每个人都在谈论 MVC，我注意到业务规则没有得到解决。 在过去的三层架构中，业务规则位于中间层。 它们在新的 MVC 中处于什么位置？
Now that everyone is talking about MVC, I notice that the business rules are not being addressed. In the old days of the 3-tier architecture, The business rules were in the middle layer. Where do they fall in the new MVC?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
您从未看到 MVC 解决“业务规则”的原因是，MVC 总的来说是一种表示模式。 它的重点是如何构建您的应用程序。 例如，模型可以被视为表示模型。 您的应用程序的模型，视图随后将呈现该模型。
但是，为了创建表示模型，您通常需要转到所有业务逻辑所在的域模型。 此时，MVC 并不规定该代码的物理位置。 是在另一层吗？ MVC 不在乎。
The reason you never see MVC address "Business Rules" is that MVC by and large is a presentation pattern. It's focused on how to structure your application. The Model, for example, can be thought of as a presentation model. The model of your application, which the view then renders.
However, in order to create the presentation model, you generally need to go to your domain models where all your business logic lives. At that point, MVC doesn't dictate where that code physically live. Is it on another tier? MVC doesn't care.
乍一看，我会说它们属于模型。 维基百科上的 MVC 条目 似乎同意：“在 MVC 中，模型代表了应用程序的信息（数据）以及用于操作数据的业务规则”。
毕竟，“业务规则”是指对应用程序涉及的域进行编码的功能算法和逻辑，而不是与输入/输出相关的逻辑。 这些与业务相关的核心逻辑不会（也不应该）根据向用户显示的内容（这是视图的域）或用户输入（主要由控制器接收）而改变。
根据我的经验，在软件开发过程中提出此类问题非常有启发性：我们发现大量被某些人认为是“业务规则”的东西，但结果却是其他东西。 如果它不是真正的业务规则，它可能不属于该模型。
At first brush, I'd say they belong in the model. The MVC Entry on Wikipedia seems to agree: "In MVC, the model represents the information (the data) of the application and the business rules used to manipulate the data".
After all, by 'Business rules' we mean the functional algorithms and logic that encode the domain that your application is involved with, as opposed to input/output related logic. These core business-related logic does not - or should not- change based upon what is being displayed to the user (which is the domain of the View) or the user input (which is primarily received by the Controller).
In my experience, asking this sort of question has been very revealing during the software development process: we found a large number of things that were considered 'business rules' by some people, but turned out to be something else. If it is not a true business rule, it might not belong to the model.
业务规则始终存在于模型中。 该模型是您可以通过完全不同的 UI 重复使用的部分。 视图显然完全依赖于 UI 选择，控制器必须从模型中获取数据并告诉视图渲染它。
将业务逻辑放入视图中是不好的，因为它将结构与表示联系在一起。
将业务逻辑放入控制器中是不好的，因为它将模型保留的数据和控制器中的规则之间的业务域分开。
Business rules always live in the model. The model is the bit that you could resuse with a completely different UI. The view is obviously completely dependent on UI choices and the controller has to take data from the model and tell the view to render it.
Putting business logic into the view is bad because it ties the structure to the presentation.
Putting business logic into the controller is bad because it splits your business domain between the data persisted by the model and the rules in the controller.
引用维基百科文章：
MVC 经常出现在 Web 应用程序中，其中视图是实际的 HTML 页面，控制器是收集动态数据并生成 HTML 内容的代码。 最后，模型由实际内容表示，通常存储在数据库或 XML 节点中，以及根据用户操作转换该内容的业务规则。
A quote from a Wikipedia Article:
MVC is often seen in web applications, where the view is the actual HTML page, and the controller is the code that gathers dynamic data and generates the content within the HTML. Finally, the model is represented by the actual content, usually stored in a database or in XML nodes, and the business rules that transform that content based on user actions.
有什么理由不能混合使用 MVC 和 Ntier 吗？ 我们的应用程序就是这样做的。 我们的控制器用于数据验证并决定进行哪些业务层调用。
OurApp.Web - Asp.net MVC 项目
OurApp.Business - 业务层库
OurApp.DataAccess - 数据层库
OurApp.Entities - 基本上所有层共享的所有“模型”
Is there any reason why you cant mix MVC and Ntier? Our application does just that. Our controllers are used for data validation and decide which Business Layer calls to make.
OurApp.Web - Asp.net MVC Project
OurApp.Business - Business Layer Library
OurApp.DataAccess - Data Layer Library
OurApp.Entities - Basically all the 'models' shared by all layers
业务规则应该位于模型中，而不是控制器中。 控制器和视图是表示层的一部分。
模型代表域的实体和功能。
控制器只是一个管理器，用于获取用户输入和请求、在模型中/模型上执行操作并将其映射到表示层中的视图。 控制器也不仅仅是中介者，视图或控制器可以对模型起作用。
Business rules should be in the model, NOT the controller. The controller and view are part of the presentation layer.
The model represents the domain's entities and functionality ..
The controller is merely a manager for taking user input and requests, performing actions in/on the model and mapping that to views in the presentation layer. The controller is not just a mediator either, the view OR controller may act upon the model.
这是一个古老的问题，但我喜欢规则存储库完全独立于应用程序的任何部分。 多个应用程序、业务层的多个实现应该能够访问业务规则存储库的静态呈现。 诸如此类的简单分离决策使得从桌面迁移 -> 例如，网络，微不足道。
在我的架构中，View -> 型号-> 控制器-> 业务层-> 规则存储库，即控制器访问业务层所呈现的粗略数据，将其提供给模型，模型将其处理为可呈现的形式，并且视图被动地显示它。 业务层可在任何表示格式中重复使用，将具有显式规则并可以使用隐式规则访问子系统。 根据设计，每个组件都不了解其上方组件的详细信息。
This is an anciently posted question, but I like a rules repository to be completely independent of any part of an application. Multiple applications, multiple implementations of a business tier, should be able to access a static rendering of a business rules repository. Simple separation decisions such as this make a migration from desktop -> web, for instance, trivial.
In my architecture, View -> Model -> Controller -> Business Tier -> Rules Repository, i.e. the controller accesses coarse data as presented by the business tier/layer, feeds it to the model which massages it into a presentable form, and the view passively displays it. The business tier, which is re-usable across any presentation format, will have explicit rules and access to a subsystem with implicit rules. By design, each component is ignorant of the details of a component above it.
我认为这个问题是一个定义问题。 在我看来，按所需顺序呈现屏幕的逻辑是一个控制器问题，我已经看到一些项目使用规则引擎来确定顺序以及需要用户输入的内容。 恕我直言，这与业务规则不同。
I think the issue is a matter of definition. It seems to me that the logic for presenting the screens in the order needed is a controller issue and I have seen some projects that use a rules engine to determine the order and what is required input from the user. This is not the same as business rules imho.
你们错了，业务规则存在于控制器中，而不是模型中......
You guys are wrong the business rules live within the controller and not the model...