Struts 1简介及存在的问题
从过去的岁月来看，Struts 1是所有MVC框架中不容辩驳的胜利者，不管是市场占有率，还是所拥有的开发人群，Struts 1都拥有其他MVC框架不可比拟的优势。Struts 1的成功得益于它丰富的文档、活跃的开发群体。当然，Struts 1是世界上第一个发布的MVC框架：Struts 1.0在2001年6月发布，这一点可能是使它得到如此广泛拥戴的主要原因。
为了使读者可以明白Struts 1的运行机制，下面将简要介绍Struts 1的基本框架。
Struts 1框架以ActionServlet作为核心控制器，整个应用由客户端请求驱动。当客户端向Web应用发送请求时，请求将被Struts 1的核心控制器ActionServlet拦截，ActionServlet根据请求决定是否需要调用业务逻辑控制器处理用户请求（实际上，业务逻辑控制器还是控制器，它只是负责调用模型来处理用户请求），当用户请求处理完成后，其处理结果通过JSP呈现给用户。
对于整个Struts 1框架而言，控制器就是它的核心，Struts 1的控制器由两个部分组成：核心控制器和业务逻辑控制器。其中核心控制器就是ActionServlet，由Struts 1框架提供；业务逻辑控制就是用户自定义的Action，由应用开发者提供。
对于大部分用户请求而言，都需要得到服务器的处理。当用户发送一个需要得到服务器处理的请求时，该请求被ActionServlet拦截到，ActionServlet将该请求转发给对应的业务逻辑控制器，业务逻辑控制器调用模型来处理用户请求；如果用户请求只是希望得到某个URL资源，则由ActionServlet将被请求的资源转发给用户。
下面就Struts 1程序流程具体分析MVC中的三个角色。
（1）Model部分
Struts 1的Model部分主要由底层的业务逻辑组件充当，这些业务逻辑组件封装了底层数据库访问、业务逻辑方法实现。实际上，对于一个成熟的企业应用而言，Model部分也不是一个简单的JavaBean所能完成的，它可能是一个或多个EJB组件，可能是一个WebService服务。总之，Model部分封装了整个应用的所有业务逻辑，但整个部分并不是由Struts 1提供的，Struts 1也没有为实现Model组件提供任何支持。
（2）View部分
Struts 1的View部分采用JSP实现。Struts 1提供了丰富的标签库，通过这些标签库可以最大限度地减少脚本的使用。这些自定义的标签库可以输出控制器的处理结果。
虽然Struts 1提供了与Ties框架的整合，但Struts 1所支持的表现层技术非常单一：既不支持FreeMarker、Velocity等模板技术，也不支持JasperReports等报表技术。
（3）Controller部分
Struts 1的Controller由两个部分组成。
― 系统核心控制器：由Struts 1框架提供，就是系统中的ActionServlet。
― 业务逻辑控制器：由Struts 1框架提供，就是用户自己实现的Action实例。
Struts 1的核心控制器对应图1.7中的核心控制器（ActionServlet）。该控制器由Struts 1框架提供，继承HttpServlet类，因此可以配置成一个标准的Servlet，该控制器负责拦截所有HTTP请求，然后根据用户请求决定是否需要调用业务逻辑控制器，如果需要调用业务逻辑控制器，则将请求转发给Action处理，否则直接转向请求的JSP页面。
业务逻辑控制器负责处理用户请求，但业务逻辑控制器本身并不具有处理能力，而是调用Model来完成处理。
Struts 1提供了系统所需要的核心控制器，也为实现业务逻辑控制器提供了许多支持。因此，控制器部分就是Struts 1框架的核心。有时候，我们直接将MVC层称为控制器层。
提示 对于任何的MVC框架而言，其实只实现了C（控制器）部分，但它负责用控制器调用业务逻辑组件，并负责控制器与视图技术（JSP、FreeMarker和Velocity等）的整合。
对于Struts 1框架而言，因为它与JSP/Servlet耦合非常紧密，因而导致了许多不可避免的缺陷，随着Web应用的逐渐扩大，这些缺陷逐渐变成制约Struts 1发展的重要因素――这也是Struts 2出现的原因。下面具体分析Struts 1中存在的种种缺陷。
（1）支持的表现层技术单一
Struts 1只支持JSP作为表现层技术，不提供与其他表现层技术，例如Velocity、FreeMarker等技术的整合。这一点严重制约了Struts 1框架的使用，对于目前的很多Java EE应用而言，并不一定使用JSP作为表现层技术。
虽然Struts 1处理完用户请求后，并没有直接转到特定的视图资源，而是返回一个ActionForward对象（可以理解ActionForward是一个逻辑视图名），在struts-config.xml文件中定义了逻辑视图名和视图资源之间的对应关系，当ActionServlet得到处理器返回的ActionForword对象后，可以根据逻辑视图名和视图资源之间的对应关系，将视图资源呈现给用户。
从上面的设计来看，不得不佩服Struts 1的设计者高度解耦的设计：控制器并没有直接执行转发请求，而仅仅返回一个逻辑视图名――实际的转发放在配置文件中进行管理。但因为Struts 1框架出现的年代太早了，那时候还没有FreeMarker、Velocity等技术，因而没有考虑与这些FreeMarker、Velocity等视图技术的整合。
提示 Struts 1已经通过配置文件管理逻辑视图名和实际视图之间的对应关系，只是没有做到让逻辑视图名可以支持更多的视图技术。
虽然Struts 1有非常优秀的设计，但由于历史原因，它没有提供与更多视图技术的整合，这严重限制了Struts 1的使用。
（2）与Servlet API严重耦合，难于测试
因为Struts 1框架是在Model 2的基础上发展起来的，因此它完全是基于Servlet API的，所以在Struts 1的业务逻辑控制器内，充满了大量的Servlet API。
看下面的Action代码片段：
//业务逻辑控制器必须继承Struts 1提供的Action类
public class LoginAction extends Action
{
//处理用户请求的execute方法
public ActionForward execute(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)throws
AuctionException
{
//获取封装用户请求参数的ActionForm对象
//将其强制类型转换为登录用的ActionForm
LoginForm loginForm = (LoginForm)form;
//当用户名为scott,密码为tiger时返回成功
if ("scott".equals(loginForm.getUsername()
&& "tiger".equals(loginForm.getPassword())
{
//处理成功，返回一个ActionForward对象
return mapping.findForward("success");
}
else
{
//处理失败，返回一个ActionForward对象
return mapping.findForward("success");
}
}
}
当我们需要测试上面Action类的execute方法时，该方法有4个参数：ActionMapping、ActionForm、HttpServletRequest和HttpServletResponse，初始化这4个参数比较困难，尤其是HttpServletRequest和HttpServletResponse两个参数，通常由Web容器负责实例化。
因为HttpServletRequest和HttpServletResponse两个参数是Servlet API，严重依赖于Web服务器。因此，一旦脱离了Web服务器，Action的测试非常困难。
（3）代码严重依赖于Struts 1 API，属于侵入式设计
正如从上面代码片段中所看到的，Struts 1的Action类必须继承Struts 1的Action基类，实现处理方法时，又包含了大量Struts 1 API：如ActionMapping、ActionForm和ActionForward类。这种侵入式设计的最大弱点在于，一旦系统需要重构时，这些Action类将完全没有利用价值，成为一堆废品。
可见，Struts 1的Action类这种侵入式设计导致了较低的代码复用。
1.2.2 WebWork简介
WebWork虽然没有Struts 1那样赫赫有名，但也是出身名门，WebWork来自另外一个优秀的开源组织：opensymphony，这个优秀的开源组织同样开发了大量优秀的开源项目，如Qutarz、OSWorkFlow等。实际上，WebWork的创始人则是另一个Java领域的名人：Rickard Oberg（他就是JBoss和XDoclet的作者）。
相对于Struts 1存在的那些先天性不足而言，WebWork则更加优秀，它采用了一种更加松耦合的设计，让系统的Action不再与Servlet API耦合。使单元测试更加方便，允许系统从B/S结构向C/S结构转换。
相对于Struts 1仅支持JSP表现层技术的缺陷而言，WebWork支持更多的表现层技术，如Velocity、FreeMarker和XSLT等。
WebWork可以脱离Web应用使用，这一点似乎并没有太多优势，因为，一个应用通常开始已经确定在怎样的环境下使用。WebWork有自己的控制反转（Inversion of Control）容器，通过控制反转，可以让测试变得更简单，测试中设置实现服务接口的Mock对象完成测试，而不需要设置服务注册。
WebWork 2使用OGNL这个强大的表达式语言，可以访问值栈。OGNL对集合和索引属性的支持非常强大。
WebWork建立在XWork之上，使用ServletDispatcher作为该框架的核心控制器，处理HTTP的响应和请求。
从处理流程上来看，WebWork与Struts 1非常类似，它们的核心都由控制器组成，其中控制器都由两个部分组成：
― 核心控制器ServletDispatcher，该控制器框架提供。
― 业务逻辑控制器Action，该控制器由程序员提供。
相对Struts 1的Action与Servlet API紧紧耦合的弱点来说，WebWork的Action则完全与Servlet API分离，因而该Action更容易测试。
WebWork的Action可以与Servlet API分离，得益于它灵巧的设计，它使用一个拦截器链，负责将用户请求数据转发到Action，并负责将Action的处理结果转换成对用户的响应。
当用户向Web应用发送请求时，该请求经过ActionContextCleanUp、SiteMesh等过滤器过滤，由WebWork的核心控制器拦截，如果用户请求需要WebWork的业务逻辑控制器处理，该控制器则调用Action映射器，该映射器将用户请求转发到对应的业务逻辑控制器。值得注意的是，此时的业务逻辑控制器并不是开发者实现的控制器，而是WebWork创建的控制器代理。
创建控制器代理时，WebWork需要得到开发者定义的xwork.xml配置文件，控制器代理以用户实现的控制器作为目标，以拦截器链中的拦截器作为处理（Advice）。
提示 WebWork中创建控制器代理的方式，就是一种AOP（面向切面编程）编程方式，只是这种AOP中的拦截器由系统提供，因此无需用户参与。如果读者需要获取更多关于AOP编程的知识，请参阅AOP相关资料，或笔者所著的《Spring 2.0宝典》一书的第6章。
开发者自己实现的业务逻辑控制器只是WebWork业务控制器的目标――这就是为什么开发者自己实现的Action可以与Servlet API分离的原因。当开发者自己的Action处理完HTTP请求后，该结果只是一个普通字符串，该字符串将对应到指定的视图资源。
指定的试图资源经过拦截器链的处理后，生成对客户端的响应输出。
上面整个过程的数据流图如图1.8所示。
与前面的Struts 1框架对比，不难发现WebWork在很多地方确实更优秀。相对Struts 1的种种缺点而言，WebWork存在如下优点：
（1）Action无需与Servlet API耦合，更容易测试
相对于Struts 1框架中的Action出现了大量Servlet API而言，WebWork的Action更像一个普通Java对象，该控制器代码中没有耦合任何Servlet API。看下面的WebWork的Action示例：
public class LoginAction implements Action
{
//该字符串常量将作为Action的返回值
private final static String LOGINFAIL="loginfail";
//该Action封装的两个请求参数
private String password;
private String username;
//password请求参数对应的getter方法
public String getPassword()
{
return password;
}
//password请求参数对应的setter方法
public void setPassword(String password)
{
this.password = password;
}
//username请求参数对应的getter方法
public String getUsername()
{
return username;
}
//username请求参数对应的setter方法
public void setUsername(String username)
{
this.username = username;
}
//处理用户请求的execute方法
public String execute() throws Exception
{
if ("yeeku".equalsIgnoreCase(getUsername())
&& "password".equals(getPassword()))
{
ActionContext ctx = ActionContext.getContext();
//将当前登录的用户名保存到Session
Map session = ctx.getSession();
session.put("username",getUsername());
return SUCCESS;
}
else
{
return LOGINFAIL;
}
}
}
在上面的Action代码中，我们看不到任何的Servlet API，当系统需要处理两个请求参数：username和password时，Action并未通过HttpServletRequest对象来获得请求参数，而是直接调用访问该Action的username和password成员属性――这两个属性由Action拦截器负责初始化，以用户请求参数为其赋值。
即使Action中需要访问HTTP Session对象，依然没有在代码中直接出现HttpSession API，而是以一个Map对象代表了HTTP Session对象。
当我们将WebWork的Action和Struts 1的Action进行对比时，不难发现Struts 1的Action确实太臃肿了，确实不如WebWork的Action那么优雅。
如果需要测试上面的Action代码，测试用例的书写将非常容易，因为execute方法中没有包含任何Servlet API，甚至没有WebWork的API。
（2）Action无需与WebWork耦合，代码重用率高
在上面的Action代码中，不难发现WebWork中的Action其实就是一个POJO，该Action仅仅实现了WebWork的Action接口，包含了一个execute方法。
Struts 1中的Action类需要继承Struts 1的Action类。我们知道，实现一个接口和继承一个类是完全不同的概念：实现一个接口对类的污染要小得多，该类也可以实现其他任意接口，还可以继承一个父类；但一旦已经继承一个父类，则意味着该类不能再继承其他父类。
除此之外，Struts 1中Action也包含了一个execute方法，但该方法需要4个参数，类型分别是ActionMapping、ActionForm、HttpServletRequest和HttpServletResponse，一个包含了这4个参数的方法，除了在Struts 1框架下有用外，笔者难以想象出该代码还有任何复用价值。但WebWork的execute方法则完全不同，该方法中没有出现任何Servlet API，也没有出现任何WebWork API，这个方法在任何环境下都有重用的价值。
得益于WebWork灵巧的设计，WebWork中的Action无需与任何Servlet API、WebWork API耦合，从而具有更好的代码重用率。
（3）支持更多的表现层技术，有更好的适应性
正如从图1.8所见到的，WebWork对多种表现层技术：JSP、Velocity和FreeMarker等都有很好的支持，从而给开发更多的选择，提供了更好的适应性。
1.2.3 Struts 2起源
经过五年多的发展，Struts 1已经成为一个高度成熟的框架，不管是稳定性还是可靠性，都得到了广泛的证明。但由于它太“老”了，一些设计上的缺陷成为它的硬伤。面对大量新的MVC框架蓬勃兴起，Struts 1也开始了血液的更新。
目前，Struts已经分化成两个框架：第一个框架就是传统Struts 1和WebWork结合后的Struts 2框架。Struts 2虽然是在Struts 1的基础上发展起来的，但实质上是以WebWork为核心，Struts 2为传统Struts 1注入了WebWork的设计理念，统一了Struts 1和WebWork两个框架，允许Struts 1和WebWork开发者同时使用Struts 2框架。
Struts分化出来的另外一个框架是Shale，这个框架远远超出了Struts 1原有的设计思想，它与原有的Struts 1的关联很少，它使用全新的设计思想。Shale更像一个新的框架，而不是Struts的升级。Shale 在很多方面与Struts存在不同之处，其中有两点最为突出：
― Struts与JSF集成，而Shale则是建立在JSF之上。
― Struts实质上是一个巨大的、复杂的请求处理器；而Shale则是一组能以任何方式进行组合的服务，简单地说，Shale是一种SOA（面向服务架构）架构。
在后面的介绍中，我们会发现，Struts 2非常类似于WebWork框架，而不像Struts 1框架，因为Struts 2是以WebWork为核心，而不是以Struts 1为核心的。正因为此，许多WebWork开发者会发现，从WebWork过渡到Struts 2是一件非常简单的事情。
当然，对于传统的Struts 1开发者，Struts 2也提供了很好的向后兼容性，Struts 2可与Struts 1有机整合，从而保证Struts 1开发者能平稳过渡到Struts 2。
1.3 Struts 2体系介绍
Struts 2的体系与Struts 1体系的差别非常大，因为Struts 2使用了WebWork的设计核心，而不是使用Struts 1的设计核心。Struts 2大量使用拦截器来处理用户请求，从而允许用户的业务逻辑控制器与Servlet API分离。
1.3.1 Struts 2框架架构
从数据流图上来看，Struts 2与WebWork相差不大，Struts 2同样使用拦截器作为处理（Advice），以用户的业务逻辑控制器为目标，创建一个控制器代理。
控制器代理负责处理用户请求，处理用户请求时回调业务控制器的execute方法，该方法的返回值将决定了Struts 2将怎样的视图资源呈现给用户。
Struts 2框架的大致处理流程如下：
浏览器发送请求，例如请求/mypage.action、/reports/myreport.pdf等。
核心控制器FilterDispatcher根据请求决定调用合适的Action。
WebWork的拦截器链自动对请求应用通用功能，例如workflow、validation或文件上传等功能。
回调Action的execute方法，该execute方法先获取用户请求参数，然后执行某种数据库操作，既可以是将数据保存到数据库，也可以从数据库中检索信息。实际上，因为Action只是一个控制器，它会调用业务逻辑组件来处理用户的请求。
Action的execute方法处理结果信息将被输出到浏览器中，可以是HTML页面、图像，也可以是PDF文档或者其他文档。此时支持的视图技术非常多，既支持JSP，也支持Velocity、FreeMarker等模板技术。
1.3.2 Struts 2的配置文件
当Struts 2创建系统的Action代理时，需要使用Struts 2的配置文件。
Struts 2的配置文件有两份：
― 配置Action的struts.xml文件。
― 配置Struts 2全局属性的struts.properties文件。
struts.xml文件内定义了Struts 2的系列Action，定义Action时，指定该Action的实现类，并定义该Action处理结果与视图资源之间的映射关系。
下面是struts.xml配置文件的示例：
<struts>
<!-- Struts 2的Action都必须配置在package里 -->
<package name="default" extends="struts-default">
<!-- 定义一个Logon的Action，实现类为lee.Logon -->
<action name="Logon" class="lee.Logon">
<!-- 配置Action返回input时转入/pages/Logon.jsp页面 -->
<result name="input">/pages/Logon.jsp</result>
<!-- 配置Action返回cancel时重定向到Welcome的Action-->
<result name="cancel" type="redirect-action">Welcome</result>
<!-- 配置Action返回success时重定向到MainMenu的Action -->
<result type="redirect-action">MainMenu</result>
<!-- 配置Action返回expired时进入ChangePassword的Action链 -->
<result name="expired" type="chain">ChangePassword</result>
</action>
<!-- 定义Logoff的Action，实现类为lee.Logoff -->
<action name="Logoff" class=" lee.Logoff">
<!-- 配置Action返回success时重定向到MainMenu的Action -->
<result type="redirect-action">Welcome</result>
</action>
</package>
</struts>
在上面的struts.xml文件中，定义了两个Action。定义Action时，不仅定义了Action的实现类，而且的定义Action的处理结果时，指定了多个result，result元素指定execute方法返回值和视图资源之间的映射关系。对于如下配置片段：
<result name="cancel" type="redirect-action">Welcome</result>
表示当execute方法返回cancel的字符串时，跳转到Welcome的Action。定义result元素时，可以指定两个属性：type和name。其中name指定了execute方法返回的字符串，而type指定转向的资源类型，此处转向的资源可以是JSP，也可以是FreeMarker等，甚至是另一个Action――这也是Struts 2可以支持多种视图技术的原因。
除此之外，Struts 2还有一个配置Struts 2全局属性的Properties文件：struts.properties。该文件的示例如下：
#指定Struts 2处于开发状态
struts.devMode = false
//指定当Struts 2配置文件改变后，Web框架是否重新加载Struts 2配置文件
struts.configuration.xml.reload=true
正如上面见到的，struts.properties文件的形式是系列的key、value对，它指定了Struts 2应用的全局属性。
1.3.3 Strut 2的标签库
Struts 2的标签库也是Struts 2的重要组成部分，Struts 2的标签库提供了非常丰富的功能，这些标签库不仅提供了表现层数据处理，而且提供了基本的流程控制功能，还提供了国际化、Ajax支持等功能。
通过使用Struts 2的标签，开发者可以最大限度地减少页面代码的书写。
看下面的JSP页面的表单定义片段：
<!-- 定义一个Action -->
<form method="post" action="basicvalid.action">
<!-- 下面定义三个表单域 -->
名字：<input type="text" name="name"/><br>
年纪：<input type="text" name="age"/><br>
喜欢的颜色：<input type="text" name="favorite"/><br>
<!-- 定义一个输出按钮 -->
<input type="submit" value="提交"/>
</form>
上面页面使用了传统的HTML标签定义表单元素，还不具备输出校验信息的功能，但如果换成如下使用Struts 2标签的定义方式：
<!-- 使用Struts 2标签定义一个表单 -->
<s:form method="post" action="basicvalid.action">
<!-- 下面使用Struts 2标签定义三个表单域 -->
<s:textfield label="名字" name="name"/>
<s:textfield label="年纪" name="age"/>
<s:textfield label="喜欢的颜色" name="answer"/>
<!-- 定义一个提交按钮 -->
<s:submit/>
</s:form>
则页面代码更加简洁，而且有更简单的错误输出。图1.10是上面使用Struts 2标签执行数据校验后的输出。
提示 Struts 2的标签库的功能非常复杂，该标签库几乎可以完全替代JSTL的标签库。而且Struts 2的标签支持表达式语言，这种表达式语言支持一个强大和灵活的表达式语言：OGNL（Object Graph Notation Language），因此功能非常强大。
1.3.4 Struts 2的控制器组件
Struts 2的控制器组件是Struts 2框架的核心，事实上，所有MVC框架都是以控制器组件为核心的。正如前面提到的，Struts 2的控制器由两个部分组成：FilterDispatcher和业务控制器Action。
实际上，Struts 2应用中起作用的业务控制器不是用户定义的Action，而是系统生成的Action代理，但该Action代理以用户定义的Action为目标。
下面是Struts 2的Action代码示例：
public class LoginAction
{
//封装用户请求参数的username属性
private String username;
//封装用户请求参数的password属性
private String password;
//username属性的getter方法
public String getUsername()
{
return username;
}
//username属性的setter方法
public void setUsername(String username)
{
this.username = username;
}
//password属性的getter方法
public String getPassword()
{
return password;
}
//password属性的setter方法
public void setPassword(String password)
{
this.password = password;
}
//处理用户请求的execute方法
public String execute() throws Exception
{
//如果用户名为scott，密码为tiger，则登录成功
if (getUsername().equals("scott")
&& getPassword().equals("tiger") )
{
return "success";
}
else
{
return "error";
}
}
}
通过查看上面的Action代码，发现该Action比WebWork中的Action更彻底，该Action无需实现任何父接口，无需继承任何Struts 2基类，该Action类完全是一个POJO（普通、传统的Java对象），因此具有很好的复用性。
归纳起来，该Action类有如下优势：
― Action类完全是一个POJO，因此具有很好的代码复用性。
― Action类无需与Servlet API耦合，因此进行单元测试非常简单。
― Action类的execute方法仅返回一个字符串作为处理结果，该处理结果可映射到任何的视图，甚至是另一个Action。
1.4 Struts 2与Struts 1的对比
经过上面简要介绍，不难发现，Struts 2确实在Struts 1上做出了巨大的改进，的确是一个非常具有实用价值的MVC框架。下面是Struts 1和Struts 2在各方面的简要对比。
― 在Action实现类方面的对比：Struts 1要求Action类继承一个抽象基类；Struts 1的一个具体问题是使用抽象类编程而不是接口。Struts 2 Action类可以实现一个Action接口，也可以实现其他接口，使可选和定制的服务成为可能。Struts 2提供一个ActionSupport基类去实现常用的接口。即使Action接口不是必须实现的，只有一个包含execute方法的POJO类都可以用作Struts 2的Action。
― 线程模式方面的对比：Struts 1 Action是单例模式并且必须是线程安全的，因为仅有Action的一个实例来处理所有的请求。单例策略限制了Struts 1 Action能做的事，并且要在开发时特别小心。Action资源必须是线程安全的或同步的；Struts 2 Action对象为每一个请求产生一个实例，因此没有线程安全问题。
― Servlet依赖方面的对比：Struts 1 Action依赖于Servlet API，因为Struts 1 Action的execute方法中有HttpServletRequest和HttpServletResponse方法。Struts 2 Action不再依赖于Servlet API，从而允许Action脱离Web容器运行，从而降低了测试Action的难度。 当然，如果Action需要直接访问HttpServletRequest和HttpServletResponse参数，Struts 2 Action仍然可以访问它们。但是，大部分时候，Action都无需直接访问HttpServetRequest和HttpServletResponse，从而给开发者更多灵活的选择。
― 可测性方面的对比：测试Struts 1 Action的一个主要问题是execute方法依赖于Servlet API，这使得Action的测试要依赖于Web容器。为了脱离Web容器测试Struts 1的Action，必须借助于第三方扩展：Struts TestCase，该扩展下包含了系列的Mock对象（模拟了HttpServetRequest和HttpServletResponse对象），从而可以脱离Web容器测试Struts 1的Action类。Struts 2 Action可以通过初始化、设置属性、调用方法来测试。
― 封装请求参数的对比：Struts 1使用ActionForm对象封装用户的请求参数，所有的ActionForm必须继承一个基类：ActionForm。普通的JavaBean不能用作ActionForm，因此，开发者必须创建大量的ActionForm类封装用户请求参数。虽然Struts 1提供了动态ActionForm来简化ActionForm的开发，但依然需要在配置文件中定义ActionForm；Struts 2直接使用Action属性来封装用户请求属性，避免了开发者需要大量开发ActionForm类的烦琐，实际上，这些属性还可以是包含子属性的Rich对象类型。如果开发者依然怀念Struts 1 ActionForm的模式，Struts 2提供了ModelDriven模式，可以让开发者使用单独的Model对象来封装用户请求参数，但该Model对象无需继承任何Struts 2基类，是一个POJO，从而降低了代码污染。
― 表达式语言方面的对比：Struts 1整合了JSTL，因此可以使用JSTL表达式语言。这种表达式语言有基本对象图遍历，但在对集合和索引属性的支持上则功能不强；Struts 2可以使用JSTL，但它整合了一种更强大和灵活的表达式语言：OGNL（Object Graph Notation Language），因此，Struts 2下的表达式语言功能更加强大。
― 绑定值到视图的对比：Struts 1使用标准JSP机制把对象绑定到视图页面；Struts 2使用“ValueStack”技术，使标签库能够访问值，而不需要把对象和视图页面绑定在一起。
― 类型转换的对比：Struts 1 ActionForm 属性通常都是String类型。Struts 1使用Commons-Beanutils进行类型转换，每个类一个转换器，转换器是不可配置的；Struts 2使用OGNL进行类型转换，支持基本数据类型和常用对象之间的转换。
― 数据校验的对比：Struts 1支持在ActionForm重写validate方法中手动校验，或者通过整合Commons alidator框架来完成数据校验。Struts 2支持通过重写validate方法进行校验，也支持整合XWork校验框架进行校验。
― Action执行控制的对比：Struts 1支持每一个模块对应一个请求处理（即生命周期的概念），但是模块中的所有Action必须共享相同的生命周期。Struts 2支持通过拦截器堆栈（Interceptor Stacks）为每一个Action创建不同的生命周期。开发者可以根据需要创建相应堆栈，从而和不同的Action一起使用。
1.5 WebWork和Struts 2对比
从某种程度上来看，Struts 2是WebWork的升级，而不是Struts 1的升级，甚至在Apache的Struts 2的官方文档都提到：WebWork到Struts 2是一次平滑的过渡。实际上，Struts 2.0其实是WebWork 2.3而已，从WebWork 2.2迁移到Struts 2.0不会比从WebWork 2.1到2.2更麻烦。
在很多方面，Struts 2仅仅是改变了WebWork下的名称，因此，如果开发者具有WebWork的开发经验，将可以更加迅速地进入Struts 2的开发领域。
下面是Struts 2与WebWork命名上存在改变（见表1.1）：
表1.1 Struts 2和WebWork成员名称的对应
Struts 2成员 WebWork成员
com.opensymphony.xwork2.* com.opensymphony.xwork.*
org.apache.Struts2.* com.opensymphony.webwork.*
struts.xml xwork.xml
struts.properties webwork.properties
Dispatcher DispatcherUtil
org.apache.Struts2.config.Settings com.opensymphony.webwork.config.Configuration
除此之外，Struts 2也删除了WebWork中少量特性：
― AroundInterceptor：Struts 2不再支持WebWork中的AroundInterceptor。如果应用程序中需要使用AroundInterceptor，则应该自己手动导入WebWork中的AroundInterceptor类。
― 富文本编辑器标签：Struts 2不再支持WebWork的富文本编辑器，如果应用中需要使用富文本编辑器，则应该使用Dojo的富文本编辑器。
― IoC容器支持：Struts 2不再支持内建的IoC容器，而改为全面支持Spring的IoC容器，以Spring的IoC容器作为默认的Object工厂。