上图是典型的MVC模式，经常被表示为：一个互相连接的三角形。对于一个基于Web的应用程序而言，是很难维护该三角形的“改变通知(state query/change notification)”这一部分。 这些东西在所有资源都在一台服务器上，而且客户端保持一个开放连接的情况下工作得非常好。如果资源分布在不同的服务器上，并且客户端不能维护一个开放的连接情况下，工作的并不理想。 许多分布式系统架构，包括web应用，在视图进行状态查询的概念时退缩了。针对这种不同，绝大多数情况是入分层的概念来设计的，层内的对象可以和同一层或者相邻层的对象进行通信。在一个复杂应用中，这可以在添加组件时，防止依赖关系呈指数增长。对于分布式应用程序而言，“分层“模式是设计中的核心模式。

   正如上图上所示，使用平面设计而不是传统的MVC设计方式。控制层处于表现层（视图）和应用程序逻辑（模式）之间。

   从MVC 上下文中，引入层模式将状态改变和状态查询的职责加于控制器之上，并伴随 着改变通知。

    每一个模块的主要职责并没有改变。流程有轻微改变，即查询状态和改变通知都

必须通过控制器。另一个改变是当视图（表现层）生成动态内容时，它使用由控制器提供的数据而不是直接由模式提供的数据。所以说这样的改变使得视图更加和模式无关了，即由控制器来选择数据并显示数据的视图，这样就从根本上去除了View 和 Model的耦合。

我们知道Sun的Java Servlet作为一个基本的平台来为基于Java的Web应用程序提供了很多重要的功能。从Servlet API我们可以发现，Servlet提供了一个基本的接口来处理HTTP的请求和响应,而且我们可以用Session的上下文或其它的上下文（如请求上下文request）来作为跟踪应用程序的用户的重要的手段。其实大部分表现层框架都有一个共性的地方：以Servlet API为基础，封装一些那些经常要处理的而且是令人厌烦的、繁琐的实现细节，比如说：在一个Web应用中，表单数据的接收是一件经常要做的事，因为有大量的来自客户端用户提交的表单，然后针对这些表单，我们总是要详细分析Http请求来取出页面表单的值来。Struts是一个比较好的MVC体系结构的框架，提供了对开发MVC系统的底层支持，采用的主要技术是Servlet，JSP和Custom tag library。

Struts框架的组件结构图

 

从上面的组件结构图我们可以看出来，Struts的核心ActionServlet是一个MVC风格的控制器，它是连接应用程序的Model和View之间的一座桥梁。

    层模式，在<<UML和模式应用>>第3版(Applying UML and Patterns)这本书讲到逻辑架构时说到了有关层模式的概念，其中有一个准则叫做：模型－视图分离原则。这个原则规定模型（领域）对象不应该直接与视图（UI）对象连接。Struts 通过提供一个控制器ActionServlet实现了Sun的 Model 2 架构，这个控制器可以用来管理JSP页面和ActionMapping来保证表现层之外的控制流决策来实现MVC/层模式，通过Struts的配置文件，JSP可以引用一个逻辑目标。控制器组件在运行时提供准确的URI。 供一个控制器Servlet实现了Sun的 Model 2 架构，其他表现设备之间的流程。Struts 通过使用ActionForward MVC/层 模式。

下表列出了Struts的核心类，即对应的经典的MVC组件职责。

核心Struts 类和MVC的对应

                            Strtuts配置文件

Struts 组件，按层索引

  在<<UML和模式应用>>这本书里提到了层模式中的组件应该只能和相同层和相邻层的组件交互。因此，Model 组件不能直接和View组件进行交互。我们还可以从上表中看出来，Struts中的大部分的组件其实是属于控制层的组件，因为Struts没有对模型层有严格的规定，我们可以用EJB或者其它的开源框架等。

实践中，控制器与视图的交互通过请求(request)，会话(session)以及Servlet平台提供的应用上下文进行(context)。 控制器和模型的交互通过文件和存储系统完成 (比如装入sturts的XML配置文档或者属性文件)，或者通过其他服务，如TCP, 创建一个到JDBC数据库的连接。