在MVC/MVP/MVPC中,您在哪里放置业务逻辑？

在MVC/MVP/MVPC设计模式中,您将业务逻辑放在何处？不,我不是指ASP.NET MVC框架(又名"Tag Soup").

有人说你应该把它放在MVC/MVPC中的"Controller"或"Presenter"中.但是,其他人认为它应该是模型的一部分.

你觉得怎么样？为什么？

这就是我的看法:

控制器用于应用逻辑; 逻辑,特定于您的应用程序如何与其所涉及的知识领域进行交互.

该模型用于独立于应用程序的逻辑.即在其所属知识领域的所有可能应用中有效的逻辑.

因此,几乎所有业务规则都将出现在模型中.

当我需要决定在哪里放置一些逻辑时,我发现一个有用的问题要问自己"这总是正确的,还是仅仅是我正在编写的应用程序的一部分？"

我拥有ASP.NET MVC应用程序结构的方式工作流程如下所示:

控制器 - >服务 - >存储库

上面的Services层是所有业务逻辑发生的地方.如果将业务逻辑放在Controller层中,则会失去在其他控制器中重用该业务逻辑的能力.

我不相信它属于控制器,因为一旦它嵌入其中就无法脱身.

我认为MVC应该在其间注入另一层:一个映射到用例的服务层.它包含业务逻辑,了解工作单元和事务,并处理模型和持久性对象以完成其任务.

控制器引用了满足其用例所需的服务.它担心将请求解组到服务可以处理的对象中,调用服务,并将响应编组发送回视图.

通过这种安排,即使没有控制器/视图对,服务也可以单独使用.它可以是本地或远程对象,以您希望的任何方式打包和部署,控制器可以处理.

控制器现在变得更接近视图.毕竟,您将用于桌面的控制器可能与用于Web应用程序的控制器不同.

我认为这种设计更注重服务.