在MVC/MVP/MVC中你把你的业务逻辑放在哪里？
在MVC/MVP/MVPC设计模式中你把业务逻辑放在哪里？ 不，我不是指 ASP.NET MVC Framework（又名“Tag Soup”）。
有人说你应该把它放在MVC/MVPC中的“Controller”或“Presenter”中。 但是，其他人认为它应该成为模型的一部分。
你觉得怎么样？为什么？
in the MVC/MVP/MVPC design pattern where do you put your business logic? No, I do not mean the ASP.NET MVC Framework (aka "Tag Soup").
Some people say you should put it in the "Controller" in MVC/MVPC or "Presenter". But, others think it should be part of the Model.
What do you think and why?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我是这样看的：
控制器用于应用程序逻辑； 逻辑特定于您的应用程序希望如何与其所属的知识领域进行交互。
该模型适用于独立于应用程序的逻辑。 即在其所属知识领域的所有可能应用中都有效的逻辑。
因此，几乎所有业务规则都将在模型中。
当我需要决定在哪里放置一些逻辑时，我发现一个有用的问题是“这总是正确的，还是仅适用于我当前正在编码的应用程序的一部分？”
This is how I see it:
The controller is for application logic; logic which is specific to how your application wants to interact with the domain of knowledge it pertains to.
The model is for logic that is independent of the application. i.e. logic that is valid in all possible applications of the domain of knowledge it pertains to.
Hence nearly all business rules will be in the model.
I find a useful question to ask myself when I need to decide where to put some logic is "is this always true, or just for the part of the application I am currently coding?"
我的 ASP.NET MVC 应用程序结构工作流程如下所示：
控制器 -> 服务-> 存储库
上面的服务层是所有业务逻辑发生的地方。 如果将业务逻辑放在控制器层中，您将无法在其他控制器中重用该业务逻辑。
The way I have my ASP.NET MVC application structure the workflow looks like this:
Controller -> Services -> Repositories
The Services layer above is where all the business logic takes place. If you put your business logic in your Controller layer, you lose the ability to re-use that business logic in other controllers.
我不相信它属于控制器，因为一旦它嵌入那里，它就无法退出。
我认为 MVC 应该在中间注入另一个层：映射到用例的服务层。 它包含业务逻辑，了解工作和事务单元，并处理模型和持久性对象以完成其任务。
控制器具有对完成其用例所需的服务的引用。 它担心将请求解编为服务可以处理的对象、调用服务并编组响应以发送回视图。
通过这种安排，即使没有控制器/视图对，该服务也可以单独使用。 它可以是控制器处理的本地或远程对象，可以以您希望的任何方式打包和部署。
控制器现在与视图的绑定更加紧密。 毕竟，您用于桌面的控制器可能与用于 Web 应用程序的控制器不同。
我觉得这个设计更偏向于服务。
I don't believe it belongs in the controller, because once it's embedded there it can't get out.
I think MVC should have another layer injected in-between: a service layer that maps to use cases. It contains business logic, knows about units of work and transactions, and deals with model and persistence objects to accomplish its tasks.
The controller has a reference to the service that it needs to fulfill its use case. It worries about unmarshalling requests into objects the service can deal with, calls the service, and marshals the response to send back to the view.
With this arrangement, the service is usable on its own even without the controller/view pair. It can be a local or remote object, packaged and deployed any way you wish, that the controller deals with.
The controller now becomes bound more closely to the view. After all, the controller you'll use for a desktop is likely to be different than the one for a web app.
I think this design is more service-oriented.
将您的业务逻辑放在域中并保持域分离。 我更喜欢演示者 -> 命令（消息命令使用NServiceBus）-> 域（带有 BC 有界上下文）-> 事件存储 -> 事件处理程序 -> 存储库（读取模型）。 如果逻辑不适合领域，则使用服务层。
请阅读 Martin Fowler、Eric Evan、Greg Young 和 Udi dahan 的文章。 他们已经定义了非常清晰的图片。
这是 Mark Nijhof 撰写的文章： http://elegantcode.com /2009/11/11/cqrs-la-greg-young/
Put your business logic in domain and keep your domain separte. I prefered Presenter -> Command (Message command use NServiceBus) -> Domain (with BC Bounded Context) -> EventStore -> Event handler -> Repository (read model). If logic is not fit in domain then use service layer.
Please read article from Martin fowler, Eric Evan, Greg Young and Udi dahan. They have define very clear picture.
Here is article written by Mark Nijhof : http://elegantcode.com/2009/11/11/cqrs-la-greg-young/
无论如何，将其放入模型中！
当然，一些用户交互必须在视图中，这将与您的应用程序和业务逻辑相关，但请尽可能避免这种情况。 具有讽刺意味的是，遵循这样的原则：用户在 GUI 中“工作”时尽可能少做事，而在“提交”或操作请求期间尽可能多地做事，这样可以带来更好的用户体验和可用性，而不是相反大约。 至少对于业务线应用程序来说是这样。
By all means, put it in the model!
Of course some of the user interaction will have to be in the view, that will be related to your app and business logic, but avoid this as much as possible. Ironically following the principle of doing as little as possible as the user is 'working' in your GUI and as much during 'submit' or action requests makes for a better user experience and usability, not the other way around. At least for line-of-business apps.
你可以把它放在两个地方。 控制器和表示层。 通过在表示层中使用一些逻辑，您可以限制返回到架构中的请求数量，这会增加系统的负载。 是的，您必须编写两次代码，但有时这正是响应式用户体验所需要的。
我有点喜欢这里所说的（http://www.martinhunter.co.nz/ articles/MVPC.pdf)
“使用 MVC，MVP 模型的演示者组件被分为两个
组件：呈现器（视图控制逻辑）和控制器（抽象目的控制逻辑）。”
You can put it in two places. The Controller and in the Presentation layer. By having some of the logic in the Presentation layer, you can limit the number of requests back into the architecture which adds load to the system. Yeah, you have to code twice, but sometimes this is what you need for a responsive user experience.
I kinda like what was said here (http://www.martinhunter.co.nz/articles/MVPC.pdf)
"With MVPC, the presenter component of the MVP model is split into two
components: the presenter (view control logic) and controller (abstract purpose control logic)."