我有两个问题:
Q1。“业务逻辑”在MVC模式中的具体位置是什么?我分不清模型和控制器。
Q2。“业务逻辑”与“业务规则”相同吗?如果不是,有什么区别?
如果你能用一个小例子来解释就太好了。
我有两个问题:
Q1。“业务逻辑”在MVC模式中的具体位置是什么?我分不清模型和控制器。
Q2。“业务逻辑”与“业务规则”相同吗?如果不是,有什么区别?
如果你能用一个小例子来解释就太好了。
当前回答
这是一个已回答的问题,但我将给出我的“一分钱”:
业务规则属于模型。 “模型”总是由(逻辑上或物理上分离的):
表示模型——一组非常适合在视图中使用的类(它针对特定的UI/表示进行定制), 域模型——模型中与ui无关的部分,以及 存储库——“模型”的存储感知部分。
业务规则存在于领域模型中,以适合表示的形式公开给“表示”模型,有时在“数据层”中复制(或强制执行)。
其他回答
业务规则在模型中。
假设您正在为邮件列表显示电子邮件。用户单击其中一封电子邮件旁边的“删除”按钮,控制器通知模型删除条目N,然后通知视图模型已更改。
也许管理员的电子邮件永远不应该从列表中删除。这是一个业务规则,该知识属于模型。视图最终可能以某种方式表示该规则——也许模型公开了一个“IsDeletable”属性,该属性是业务规则的一个功能,因此视图中的删除按钮对于某些条目是禁用的——但视图中不包含规则本身。
模型是数据的最终把关人。您应该能够在不接触UI的情况下测试业务逻辑。
将业务层放在MVC项目的模型中是没有意义的。
假如你的老板决定把演示层换成别的东西,你就完蛋了!业务层应该是一个单独的程序集。Model包含来自业务层的数据,这些数据传递给视图进行显示。然后在post中,例如,模型绑定到驻留在业务层的Person类,并调用PersonBusiness.SavePerson(p);其中p是Person类。以下是我所做的(BusinessError类没有,但也会在BusinessLayer中):
A1:业务逻辑进入MVC的模型部分。Model的作用是包含数据和业务逻辑。另一方面,控制器负责接收用户输入并决定要做什么。
A2:业务规则是业务逻辑的一部分。他们有一种关系。业务逻辑具有业务规则。
看看维基百科中关于MVC的条目。转到概览,其中提到MVC模式的流程。
还可以查看维基百科中的Business Logic条目。上面提到,业务逻辑由业务规则和工作流组成。
为什么不引入一个服务层呢?这样你的控制器就会精简,可读性更强,所有的控制器功能都是纯粹的动作。您可以根据需要在服务层中分解业务逻辑。代码可重用性很高。对模型和存储库没有影响。
Model =用于CRUD数据库操作的代码。
Controller =响应用户操作,并根据特定于组织的业务规则将用户的数据检索或删除/更新请求传递给模型。这些业务规则可以在助手类中实现,如果不是太复杂的话,也可以直接在控制器操作中实现。控制器最后要求视图更新自己,以便以新显示的形式给用户反馈,或者像'updated, thanks'之类的消息,
View =基于对模型的查询生成的UI。
关于业务规则应该放在哪里,没有硬性规定。在一些设计中,它们进入模型,而在另一些设计中,它们包含在控制器中。但我认为最好还是把它们放在控制器里。让模型只关心数据库连通性。