控制器属于表示层？

表示层包含视图和控制器。
不得将 MVC 体系结构误认为是多层/层体系结构（尤其是 3 层体系结构）。大多数时候，模型/视图/控制器不是Web应用程序的主要设计，它只是多层/层体系结构的子集。

看看这个过于简化的方案（你可以在专用的数据访问层中拥有DAO，但这在本文中并不重要）：

Spring MVC是一个演示框架：它处理控制器和视图。但是为什么在春季MVC中使用“M”？只是因为，像许多其他表示框架一样，它自然地处理模型/实体（“M”）的表示。这种表示形式是控制器中使用的表示形式，显示在视图中，提交到表单中等。这就是为什么框架被称为Spring MVC，即使模型/实体不是预感层的一部分。

我认为它是这个框架的一个好名字，因为它真的是面向“MVC”的。实际上，模型/实体的表示可以是：

• direct：框架直接处理模型/实体对象
• 间接：框架处理表单对象或DTO，其中包含与一个或多个实体相关的信息

Spring的建议是直接使用模型/实体（“M”）对象：

可重用的业务代码，无需重复。使用现有业务对象作为命令或表单对象，而不是镜像它们来扩展特定的框架基类。

这就是为什么我说这个框架非常“MVC”导向，与其他框架相比，比如Struts，你必须使用不同的表单对象。

一些有趣的链接：

• 多层和MVC架构之间的比较，来自维基百科
• 这篇博客文章介绍了 ASP.NET 中的 3 层体系结构
• 此 3 层体系结构的博客图像
• DispatcherServlet 章节来自 Spring 的文档

控制器控制表示层逻辑。对于所有业务代码、事务性用例、持久性等，它通常委托给服务层。

一种典型的方法是将事务性服务实现为弹簧豆，并将这些弹簧豆注入控制器中。典型用例：创建新产品：

1. 控制器从浏览器接收命令 Bean
2. 它验证所有必需的数据是否存在，如果没有，则重新显示产品创建页面，并显示错误消息
3. 它调用服务豆来创建产品
4. 服务 Bean 在事务中运行。它从数据库中获取产品类别，将产品附加到其类别，根据当前定价策略计算产品的价格，向外部应用程序发送 JMS 消息，并返回所创建产品的 ID
5. 控制器将重定向到产品详细信息页面，使用所创建产品的 ID 作为 URL 参数。