MVC中的业务逻辑

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (22)

我有两个问题:

Q1.在MVC模式中,“业务逻辑”究竟在哪里?我混淆了模型和控制器。

Q2.“业务逻辑”与“业务规则”相同吗?如果没有,有什么不同?

如果你能用一个小例子来解释,那就太好了。

提问于
用户回答回答于

商业规则在模型中适用。

比如说你在为邮件列表显示电子邮件。用户单击电子邮件旁边的“删除”按钮,控制器通知模型删除条目N,然后通知模型更改的视图。

也许管理员的电子邮件永远不应该从列表中删除。这是商业规则,知识属于模型。这个观点最终可能代表这个规则--也许模型公开了一个“IsDeletable”属性,它是业务规则的一个函数,因此对某些条目禁用了视图中的DELETE按钮--但是该规则本身并不包含在视图中。

模型最终是数据的守门人。应该能够测试您的业务逻辑,而无需接触UI。

用户回答回答于

最重要的是:

我相信你把MVC模式和基于n层的设计原则混在了一起.

使用MVC方法并不意味着不应该对应用程序进行分层。

如果看到MVC更像是表示层的扩展,它可能会有所帮助。

如果将非表示代码放入MVC模式中,可能很快就会在一个复杂的设计中结束。

上面写着:

今天,mvc和类似的模型-视图-演示者(Mvp)是关注点分离的设计模式,只适用于表示层一个更大的系统。

谈论一个企业Web应用从UI到业务逻辑层的调用应该放在(表示)控制器中。

这是因为控制器实际上处理对特定资源的调用,通过调用业务逻辑查询数据,并将数据(模型)链接到适当的视图。

告诉你商业规则进入了模型。

这也是事实,但他混淆了(表示)模型(mvc中的‘M’)和基于层的应用程序设计的数据层模型。

因此,将与数据库相关的业务放置在规则在应用程序的模型(数据层)中。

但是不应该将它们放在MVC结构表示层的模型中,因为这只适用于特定的UI。

此技术独立于WHEATHER,使用的是域驱动设计或基于事务脚本的方法。

表示层:模型-视图-控制器

业务层:域逻辑-应用程序逻辑

数据层:数据存储库.数据访问层

上面看到的模型意味着您有一个使用MVC、DDD和数据库独立数据层的应用程序。

这是设计更大的企业Web应用程序的一种常见方法。

扫码关注云+社区