所以我假设人们仍然在 Controller 逻辑之外使用业务层？如果是这样，那条灰线在哪里绘制，您没有将什么放入您的 Controller 类中，您将在您的业务层项目中，反之亦然？在我看来， Controller 完全摆脱了 MVC 应用程序中对业务层的需求。
最佳答案
在我看来， Controller 层是 View 的一部分。您所说的业务层我称之为服务(不是 Web 服务；这只是众多部署选择中的一种)。
业务层了解用于实现用户目标的用例和工作单元。
Controller 是关于验证、绑定(bind)和编码请求，确定需要哪个服务来完成请求并将值传递给它，解码响应并将其路由到下一个适当的 View 。
所以我同意你标题中提出的假设: Controller !=服务。
Smalltalk 的经典模式是模型- View - Controller ，它不同意我的说法，将 View 和 Controller 分成不同的层。
我所描述的是在 Web 和桌面的 Java 框架中实现的内容。 View 技术的改变通常也意味着改变 Controller 。
因此，如果 Smalltalk 习语是模型- View - Controller ，则更现代的方法看起来像 View -> Controller ->服务->模型/持久性。模型意味着“领域对象”，它独立于所有 View 技术。
关于asp.net - Controller !=业务层？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2304653/