所以我假设人们仍然只使用控制器逻辑之外的业务层？如果是这样，绘制的灰线在哪里，你在控制器类中没有放入你的业务层项目，反之亦然？在我看来，控制器完全不需要在MVC应用程序中使用业务层。
答案 0 :(得分：9)
在我看来，控制器层是视图的一部分。您所谓的业务层我称之为服务（不是 Web服务;这只是众多部署中的一种选择）。
业务层了解用于完成用户目标的用例和工作单元。
控制器完全是关于验证，绑定和编组请求，确定满足请求所需的服务并将值传递给它，解组响应并将其路由到下一个适当的视图。
所以我同意你的标题中提出的假设：控制器！=服务。
来自Smalltalk的经典模式是模型 - 视图 - 控制器，它不同意我的观点，将视图和控制器分成不同的层。
我所描述的是在Java框架中为Web和桌面实现的内容。视图技术的改变通常意味着改变控制器。
因此，如果Smalltalk习语是模型 - 视图 - 控制器，则更现代的方法看起来像view-＆gt; controller-＆gt; service-＆gt;模型/持久性。模型意味着“域对象”，它独立于所有视图技术。
答案 1 :(得分：8)
该行不是“灰色”。这是绝对的，绝对的。
模型（或“业务层”）适用于任何演示文稿。 GUI，命令行，web。并且它不需要使用GUI（视图+控件）包装命令行应用程序或Web应用程序来包装任何更改。
当您根本没有演示或控制功能时，您知道您已正确完成了模型（“业务层”）。此外，它非常完整，任何GUI都可以直接使用它。
答案 2 :(得分：3)
简单地说：
遵循Eric Evans的领域驱动方法，“业务层”包含：
另请注意，Domain模型不是数据访问层。它可能封装数据访问，但不是数据访问层本身。