struts

Struts 关于自己要说的第一句话就是：框架

…鼓励应用架构基于Model 2 方法，即经典的MVC 设计模式的变体

这句话打消了一些 web 开发者的疑虑，对那些还没深入Model 2 或 MVC 的人来说却更

加疑惑了。事实上，没有深入了解 MVC 和Sun Model 2，要理解很多Struts 的文章都很

困难。

2.4.1. MVC的演化

如 2.1 节所说, Model/View/Controller 原本是建立Smalltalk 应用的框架。框架支持代

表应用状态、屏幕表现和控制流的3 个类，分别叫做 Model, View, 和 Controller。

Smalltalk MVC 框架在颇为流行的书Design Patterns: Elements of Reusable

Object-Oriented Software[Go4]是作为案例来研究的。Design Patterns 这本书有四个作者，

被称为“四人帮GoF”。

 
 

Design Patterns 中的MVC 例子称为通知/订阅者（notify/subscribe）协议和观察者（Observer）

模式的使用。例子的基础是，对同一数据，系统可能需要不同的显示视图，比如条形图、饼

图、数据表格等等。这是一个划分应用的精彩理由，经常被重复引用。

 

在图2-6 所示的例子中，每种视图可能在同一时间显示给不同的用户。应用必须保证在其下

面的数据或者模型改变时视图的更新。为改变模型，用户提交一个请求给控制器，由控制起

来配合改变模型。数据视图必须跟着改变，以反映最近的模型改变状态。

Smalltalk MVC 方案使用观察者通知模式。在这种模式下，每个视图注册为一个模型数据

的观察者。然后模型可以通过发送消息给所有这册观察者，通知它们相关的改变。其为

Smalltalk MVC 框架已经通用化了，他也可以将它应用到其他平台上面。

 

在图2-6 所示的例子中，每种视图可能在同一时间显示给不同的用户。应用必须保证在其下

面的数据或者模型改变时视图的更新。为改变模型，用户提交一个请求给控制器，由控制起

来配合改变模型。数据视图必须跟着改变，以反映最近的模型改变状态。

Smalltalk MVC 方案使用观察者通知模式。在这种模式下，每个视图注册为一个模型数据

的观察者。然后模型可以通过发送消息给所有这册观察者，通知它们相关的改变。其为

Smalltalk MVC 框架已经通用化了，他也可以将它应用到其他平台上面。

2.4.2. Model 2的出现

JSP 的意图是使创建动态页面更容易。JSP 首先是作为servlet 的替代引入的，还有就是MS

的ASP。Servlet 的强大功能当作易于创建服务器页面的工具提供给开发者。但强大的功能

伴随着巨大的责任。很多团队发现，如果他们一不小心，他们的项目就会因为纠缠如麻的页

面变的容易崩溃。进一步的特性需要使用复杂的脚本程序。但脚本程序是非常难于重用的—

除非你在页面间把代码“拷贝粘贴”。

工具页面也可以包括进来，但它们很难被组织在一起，并且造成非常丑陋的“资源”树。有

些东西会出错。

很多开发人员很快意识到， JSP 和servlet 可以一起使用来部署web 应用。Servlet 可以

应付控制流，而 JSP 则可专注于讨厌的编写HTML 的任务。在这种情况下，结合使用 JSP

和 servlet 开始被称为Model 2 (单独使用JSP 称为Model 1)。

当然，从 Sun 那里仍然没什么新东西... 而且很多人很快指出 JSP Model 2 类似于经典的

Model-View-Controller 架构。

在很多场合，现在交互使用Model 2 和 MVC 这两个词已经很平常了，虽然还有一些争论，

即一个应用是否是 MVC，以及是否支持经典的观察者通知模式。没有观察者通知的

Model-View-Controller 有时被称为MVC2 或Web MVC。.

2.4.3. 应用层—视图之间的去耦合

Model 2 被认为区别于MVC 的一个原因是，观察者/通知模式不能在web 环境内工作的

很好。HTTP 是一个 “拉” 的协议: 客户请求然后服务器响应。没有请求就没有响应。观察

者模式需要一种“推”协议来进行通知，以便服务器能在模型改变时将信息推送到客户端。

虽然也有一些方法能模拟将数据推送到客户端，但这和基本情况相悖，并且会视为是个权宜

之计的修补。

图 2-7 MVC 通常表示为3 个互相连接的组件

图2-7 是典型的Model-View-Controller 范式，经常被表示为：一个互相连接的三角形。在

web 应用中维护范式中的“通知改变”部分是非常困难的。

这些东西在所有资源都在一台服务器上，而且客户端保持一个开放连接的情况下工作得非常

好。如果资源分布在不同的服务器上，并且客户端不能维护一个开放的连接情况下，工作的

并不理想。

许多分布式系统架构，包括 web 应用，在视图进行状态查询的概念时退缩了。绝大多数情

况下，远程应用是按层模式[POSA]设计的。基本上，层模式下，层内的对象可以和同一层

或者相邻层的对象进行通信。在一个复杂应用中，这可以在添加组件时，防止依赖关系呈指

数增长。在设计远程应用时，分层是一个核心模式。

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

改变通知。

 

 

图 2-8 Web 应用的层模式

如图2-8 ，分层的web 应用使用一种比传统MVC 模式更加“扁平”的模式。控制器被夹

在表现层(View) 和应用逻辑 (Model)之间。

每个组件的主要职责并没有改变。流程有轻微改变，即查询状态和改变通知都必须通过控制

器。另一个改变是，当视图，或者表现层需要渲染动态页面时，它使用从控制器传递的数据

而不是直接来自于模型层。这种改变去除了View 和 Model 的耦合，允许控制器选择数据

和显示这些数据的视图。

2.4.4. Struts如何实现Model 2, MVC, 和分层

Struts 通过提供一个控制器Servlet 实现了Sun 的 Model 2 架构，这个控制器可以用来管

理JSP 页面和其他表现设备之间的流程。Struts 通过使用ActionForward和ActionMapping

来保证表现层之外的控制流决策来实现 MVC/层模式。JSP 可以引用一个逻辑目标。控制

器组件在运行时提供准确的URI。

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

表格 2.2 核心 Struts 类和MVC 的对应

类 描述

 

 

除了这些核心类， Struts 使用一些配置文件和视图助手（view helpers）来沟通控制器和

模型。下表列出了Struts 配置文件和描述了他们在架构中的角色。

表格 2.3 Strtuts 配置文件

文件 目的

ApplicationResources.properties 存储本地化信息和标签，以使应用可以国际化

struts-config.xml 存储控制器对象的缺省配置，包括模型支持的用户指向，

状态改变，状态查询

 

2.5.1. 总图

 

 图 2-9 Struts 请求-相应流程

图2-9 以UML以次序图的方式展示了Struts 请求-响应流程。我们来按这个请求-响应流

程走一遍。 括号内的数字请参照图11中的相关地方：