asp.net-mvc - 使用 mvc 将业务逻辑放入应用程序的 asp.net 的创建者的建议是什么？

Question

上网查了一下，发现有人说逻辑应该放在应用ViewModel里面，也有人说应该Controller放在asp.net with mvc应用里面。

所以我无法得出结论。

1. 对此的官方（带有 MVC 的 asp.net 的创建者）的建议是什么？
2. 决定它的理由是什么？（explanations和examples）？

Answer 1

View models should only contain logic relevant to presentation. Definitely no business logic.

Business logic shouldn't really go in controllers either. Controllers should be coordinators of the components that are recruited in responding to requests.

For all but the most trivial of applications, you aught to create a services layer that implements business logic and manipulates/persists models.

For larger applications you might also have a dedicated business domain layer accessed by the service layer.

I have a library that I've found useful for implementing and co-locating the domain/rules/workflow in MVC (and other) applications. It's here.

Answer 2

我目前无法提供源或参考（根据您的要求），但业务逻辑应该放在控制器的操作方法中，或者在操作方法调用的另一层中（例如后端 Web 服务，如果您的 ASP.NET MVC应用程序仅用作现有应用程序的前端，就像 OWA 之于 Exchange Server）。

这个理由的核心是“关注”的概念，在这种情况下，ViewModel 对象应该只关注 View 和 Controller('s Actions) 之间的数据传输和验证（而不是验证）。在 ASP.NET MVC 中，ViewModel 类应该是一个 POCO（普通旧 CLR 对象），仅包含与视图中用户提供的数据相对应的属性。在我自己的项目中，我对此进行了扩展，包括将数据从业务实体转换为 ViewModel 对象，而不是直接在控制器的操作中填充属性，我还使用对 MVC 管道所做的修改来执行我自己的验证逻辑。