MVC：业务逻辑放在哪里？

Question

MVC：业务逻辑放在哪里？

c#asp.net-mvcmodel-view-controllerbusiness-logic

86

首先，我看到了很多类似的问题，但是没有足够的解释。如果我的问题不好或需要删除，我会理解的。

例如，我看过这个问题，有一个被投票赞同45次以上的回答说他建议将业务逻辑放在模型中，这听起来很合理。

然而，我第一个大项目中我把所有的业务逻辑都放在了控制器中，因为我没有质疑这些事情，并且看了一下AccountController是自动添加的，如果你选择MVC和表单认证。所有的方法看起来都很杂乱。或者也许这是可能添加的最少量的代码，我忽略了些什么？

一个YouTube上的人问我是否正确地将所有的逻辑都放到了他的模型中，起初我是不！然后我开始想，也许他是对的！？

那么，我的业务逻辑应该放在哪里呢？ 如果是在模型类中，那么在控制器中的方法中应该考虑多少行代码才算健康？在控制器中调用模型中的某个方法并返回到视图中，最多只需一行代码吗？

- Andrius Naruševičius

1

业务逻辑放在控制器中。模型逻辑放在模型中。模型逻辑是专门处理模型的事物，如设置器/获取器/属性/添加器/删除器等。 - crush

1

@crush：我不同意。据我的阅读，“模型对象保存应用程序的数据和‘业务逻辑’”，而“控制器对象将模型和视图对象联系在一起”。 - ChiefTwoPencils

@BobbyDigital - 你能提供源链接吗？ :) - Andrius Naruševičius

当然，这在《The Big Nerd Ranch Guide》中正确使用MVC的解释中有提到，但不幸的是，您必须购买该书以确认此内容。 - ChiefTwoPencils

我得说，刚刚在一本C#书里试图确认这个问题，在asp.net中业务逻辑层位于中间层，顶层是用户界面(UI)，中间层是控制器(controller)，底层是数据库(db)。但他们并没有特别/明确地讨论MVC。这来自于C#程序员必备 :) - ChiefTwoPencils

我很难想象像支付这样的逻辑工作流程在该模型中如何运作...另一个业务层选项是：http://blog.diatomenterprises.com/asp-net-mvc-business-logic-as-a-separate-layer/ - KCD

12个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Nikitesh · Answer 1

我也希望保持模型的简洁。MVC控制器只应用于调用，也应保持简洁。因此，根据其重复使用性、敏感性和相关性，可以编写业务逻辑。
1.WebApi控制器：使用WebApi控制器的优点是，您可以将其作为服务公开给其他设备，从而使代码可重用。
2.BAL / Common组件：有一些具有特定用途且无法公开为API的逻辑可以推入此类中。
3.存储库：所有与数据库相关的查询都添加到存储库中。可以有一个通用存储库来实现所有功能（CRUD操作），或者为每个表格创建特定的存储库，具体取决于要执行的操作。

- Otta Augusto · Answer 2

我知道这是关于MVC的问题，但是我认为我提供的示例（Web API）会很有用。

我正在开发我的第一个Web API，并且正在重复使用来自其他应用程序的业务逻辑。具体而言，它来自外部DLL，因此我的API仅用于“与SAP解决方案交谈”，接收来自PO的请求并发送响应。

如何将我的逻辑（已经实现）放入我的控制器中？我不需要它。我的控制器只会接收、验证请求和组合响应以发送数据回来。

我正在使用ViewModel类，并且它们必须具有映射函数，只需从TransferObjects（来自外部DLL）中读取信息并将其转换为ViewModel即可。

我不喜欢我的应用程序（在这种情况下是Web API）持有业务逻辑，我认为这样会失去可重用性。

我正在将我的业务逻辑视为注入到控制器中的依赖项。

我对遗留代码进行了大量重构，以提供可单元测试的解决方案，我不得不为遗留代码创建了许多接口，并实施一些设计模式，以提供此解决方案。

在我看来，业务层必须是应用程序的一部分，最好放在另一个类库中。这样你的应用程序就会有一个真正的分离概念实现。

当然，如果你的核心（业务）是你的应用程序（API/网站），则业务规则将被实现到你的MVC类中。但是，如果未来你想开发一个新的应用程序，并且某些业务规则相同，我敢打赌，你将面临许多问题，只是为了维护在两个应用程序中实现的相同逻辑。