【发布时间】：2010-02-21 03:30:48
【问题描述】：
所以我假设人们仍然在控制器逻辑之外使用业务层？如果是这样，那条灰线在哪里绘制，您没有将什么放入您的控制器类中，您将在您的业务层项目中，反之亦然？在我看来，控制器完全摆脱了 MVC 应用程序中对业务层的需求。
【问题讨论】：
标签： asp.net asp.net-mvc
【发布时间】：2010-02-21 03:30:48
【问题描述】：
在我看来，控制器层是视图的一部分。您所说的业务层我称之为服务（不是 Web 服务；这只是众多部署选择中的一种）。
业务层了解用于实现用户目标的用例和工作单元。
控制器负责验证、绑定和编组请求，确定完成请求所需的服务并将值传递给它，解组响应并将其路由到下一个适当的视图。
所以我同意你在标题中提出的假设：控制器！=服务。
来自 Smalltalk 的经典模式是 Model-View-Controller，它不同意我的说法，将视图和控制器分成不同的层。
我所描述的是在用于 Web 和桌面的 Java 框架中实现的内容。视图技术的改变通常也意味着控制器的改变。
因此，如果 Smalltalk 惯用语是模型-视图-控制器，则更现代的方法看起来像视图->控制器->服务->模型/持久性。模型意味着“领域对象”，它独立于所有视图技术。
【讨论】：
-
控制器层是视图的一部分？模型-视图-控制器名称代表三个完全独立的层。
-
不，控制器和视图紧密相连。我知道历史将它们视为独立的事物，但这不是现代解释。它更像是 Smalltalk、GoF 视图。
这条线不是“灰色的”。这是赤裸裸的，绝对的。
模型（或“业务层”）适用于任何演示文稿。 GUI、命令行、Web。并且它不需要任何更改以使用 GUI（视图+控件）、命令行应用程序或 Web 应用程序进行包装。
当根本没有演示或控制功能时，您知道您已经正确地完成了模型（“业务层”）。此外，它非常完整，任何 GUI 都可以直接使用它。
【讨论】：
简单地说：
- 控制器应包含特定于应用程序的逻辑。
- “业务层”应包含业务逻辑。
遵循 Eric Evans 的领域驱动方法，“业务层”包含：
- 服务层：界面围绕用例场景设计
- 领域模型：核心领域对象、实体、值对象等。
- 数据访问对象：存储库
另请注意，域模型不是数据访问层。它可能封装了数据访问，但不是数据访问层本身。
【讨论】：