27

在 MVC/MVP/MVPC 设计模式中，您将业务逻辑放在哪里？不，我不是指 ASP.NET MVC 框架（又名“标签汤”）。

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

你怎么看，为什么？

4

6 回答 6

76

这就是我的看法：

控制器用于应用程序逻辑；特定于您的应用程序希望如何与其相关的知识领域进行交互的逻辑。

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

因此，几乎所有业务规则都将包含在模型中。

当我需要决定在哪里放置一些逻辑时，我会问自己一个有用的问题是“这总是正确的，还是仅针对我当前正在编码的应用程序的一部分？”

于 2009-02-10T21:17:56.663 回答
43

我的 ASP.NET MVC 应用程序结构的工作流程如下所示：

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

上面的服务层是所有业务逻辑发生的地方。如果您将业务逻辑放在控制器层中，您将失去在其他控制器中重用该业务逻辑的能力。

于 2009-02-10T21:36:40.707 回答
14

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

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

控制器具有对实现其用例所需的服务的引用。它担心将请求解组为服务可以处理的对象，调用服务，并编组响应以发送回视图。

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

控制器现在变得更紧密地绑定到视图。毕竟，用于桌面的控制器可能与用于 Web 应用程序的控制器不同。

我觉得这个设计更注重服务。

于 2009-02-10T21:25:08.440 回答
3

将您的业务逻辑放在域中并保持您的域独立。我更喜欢 Presenter -> Command (Message command use NServiceBus) -> Domain (with BC Bounded Context) -> EventStore -> Event handler -> Repository (read model)。如果逻辑不适合域，则使用服务层。

请阅读 Martin fowler、Eric Evan、Greg Young 和 Udi dahan 的文章。他们定义了非常清晰的画面。

这是 Mark Nijhof 写的文章：http: //elegantcode.com/2009/11/11/cqrs-la-greg-young/

于 2010-09-17T03:52:01.203 回答
2

无论如何，把它放在模型中！

当然，一些用户交互必须在视图中，这将与您的应用程序和业务逻辑相关，但尽可能避免这种情况。具有讽刺意味的是，遵循用户在您的 GUI 中“工作”时尽可能少做的原则，在“提交”或操作请求期间尽可能多地做，这会带来更好的用户体验和可用性，而不是相反。至少对于业务线应用程序而言。

于 2010-08-17T17:49:55.083 回答
1

你可以把它放在两个地方。控制器和表示层。通过在表示层中包含一些逻辑，您可以限制返回到架构中的请求数量，这会增加系统的负载。是的，您必须编写两次代码，但有时这正是响应式用户体验所需要的。

我有点喜欢这里所说的（http://www.martinhunter.co.nz/articles/MVPC.pdf）

“使用 MVPC，MVP 模型的 Presenter 组件分为两个组件：Presenter（视图控制逻辑）和控制器（抽象目的控制逻辑）。”

于 2009-02-10T21:36:23.797 回答