在MVC / MVP / MVPC设计模式中，您在哪里放置业务逻辑？不，我不是指ASP.NET MVC框架（又名“Tag Soup”）。
有人说你应该把它放在MVC / MVPC中的“Controller”或“Presenter”中。但是，其他人认为它应该是模型的一部分。
您的想法和原因是什么？
答案 0 :(得分：70)
这就是我的看法：
控制器用于应用逻辑;逻辑，特定于您的应用程序如何与其所涉及的知识领域进行交互。
该模型用于独立于应用程序的逻辑。即在其所属知识领域的所有可能应用中有效的逻辑。
因此，几乎所有业务规则都将出现在模型中。
我找到一个有用的问题，当我需要决定在哪里放置一些逻辑时，问自己“这是否总是正确的，或者仅仅是我正在编写的应用程序的一部分？”
答案 1 :(得分：40)
我拥有ASP.NET MVC应用程序结构的方式工作流程如下所示：
控制器 - ＆gt;服务 - ＆gt;存储库
上面的服务层是所有业务逻辑发生的地方。如果将业务逻辑放在Controller层中，则会失去在其他控制器中重用该业务逻辑的能力。
答案 2 :(得分：13)
我不相信它属于控制器，因为一旦嵌入它就无法离开。
我认为MVC应该在其间注入另一层：一个映射到用例的服务层。它包含业务逻辑，了解工作单元和事务，并处理模型和持久性对象以完成其任务。
控制器引用了满足其用例所需的服务。它担心将请求解组到服务可以处理的对象，调用服务，并将响应编组发送回视图。
通过这种安排，即使没有控制器/视图对，服务也可以单独使用。它可以是本地或远程对象，以控制器处理的任何方式打包和部署。
控制器现在变得更接近视图。毕竟，您将用于桌面的控制器可能与用于Web应用程序的控制器不同。
我认为这种设计更注重服务。
答案 3 :(得分：3)
将您的业务逻辑放在域中并保持您的域名部分。我更喜欢Presenter - ＆gt;命令（消息命令使用NServiceBus） - ＆gt;域（具有BC有界上下文） - ＆gt; EventStore - ＆gt;事件处理程序 - ＆gt;存储库（读取模型）。如果逻辑不适合域，则使用服务层。
请阅读Martin fowler，Eric Evan，Greg Young和Udi dahan撰写的文章。他们定义了非常清晰的画面。
以下是Mark Nijhof撰写的文章：http://elegantcode.com/2009/11/11/cqrs-la-greg-young/
答案 4 :(得分：2)
一定要把它放在模型中！
当然，一些用户交互必须在视图中，这将与您的应用和业务逻辑相关，但尽可能避免这种情况。具有讽刺意味的是遵循用户在GUI中“工作”的尽可能少的原则以及在“提交”或操作请求期间尽可能少的原则，从而实现更好的用户体验和可用性，而不是其他方式周围。至少对于业务线应用程序。
答案 5 :(得分：1)
你可以把它放在两个地方。 Controller和Presentation层。通过在表示层中使用一些逻辑，您可以将请求的数量限制回到体系结构中，这会增加系统的负载。是的，你必须编写两次代码，但有时这是你需要的响应式用户体验。
我有点像这里所说的那样（http://www.martinhunter.co.nz/articles/MVPC.pdf）
“使用MVPC，MVP模型的演示者组件分为两部分 组件：演示者（视图控制逻辑）和控制器（抽象目的控制逻辑）。“