【转】struts2.0新特性以及和struts1.2的区别

Struts2.0

Struts自推出以来不断受到开发者的追捧，其最新版本Struts 2.0亦代表了下一代Java Web开发的新趋势。Struts 2.0框架具有一系列丰富的特性，对大型开发社区很有帮助，而且，从Struts 1迁移到Struts 2也不是很困难。

Apache Struts（简称Struts）是一种非常流行的Web框架，可用于使用Java企业版（JEE）开发Web应用。Struts项目是负责开发及维护 Struts框架的开源社区。Struts在2001年7月发布，目前已成为使用JEE开发Web应用的事实上的标准。而社区新近发布的Struts 2.0更是一种精致、可扩展的框架，可用于使用Java代码来开发企业就绪的Web应用。该框架旨在简化从构建、部署到日常维护的整个应用开发周期。

设计Struts框架的目的是为了让开发人员可以构建一种数据库代码、页面设计代码和控制流程代码不混合在一起的服务器小程序或者JavaServer Pages。因为，要是代码混合在一起，随着应用越来越庞大，就会变得难以维护。Struts框架基于MVC架构，可以帮助开发人员利用明确的关注点分离（separation of concerns）原则，开发动态Web应用。

Struts框架提供了自己的Web控制器组件来处理控制流程 逻辑。至于视图，它集成了其他技术，譬如JavaServer Pages（包括JSTL和JSF）、Velocity模板引擎和XSLT。至于模型，它使用JDBC、 EJB、Hibernate或者iBATIS等技术来访问数据。

Struts 1.0非常成熟，因此得到众多开发社区的有力支持，而且说明文档内容完备。不过在过去的几年里，许多开源社区的Web框架纷纷登台亮相，所以它需要跟上 Web应用需求不断变化的形势，这就有必要构建下一代Struts框架。力求满足这个要求的初始提案是Struts Ti，这种简化的MVC Model 2框架可用于让需要更少配置、更好结构和控制器特性的人开发Web应用。人们考虑用来实现这个目的的另一个框架是Apache Shale，不过，Shale是基于组件的一种框架，它立足于JSF。Shale开发社区不愿与Struts联合，决定继续把Shale作为一个顶级项目来开发。

WebWork项目由Open Symphony社区启动，面向Struts开发社区。它旨在满足那些希望寻求类似Struts的一种框架，但有更好特性的人的需要。WebWork框架于2002年发布。独立运作了几年后， WebWork和Struts两个社区在2005年12月联合起来，开发了新版本的Struts，即Struts 2。Struts 2实际上就是Struts 1与WebWork的结合体。Struts的这个新版本更易使用，更接近Struts框架的最初版本。

 

基于MVC架构的Struts 2
如前所述，Struts框架基于MVC架构。Struts 2具有一种灵活的控制层，基于Java过滤器、JavaBean、 ResourceBundle、Locale和XML等诸多标准技术上，还基于OGNL和XWork等各种Open Symphony包。
至于模型，该框架可与JDBC、EJB及其他框架（包括Hibernate、iBATIS和Cayenne）等标准的数据访问技术相互联系。至于视图，该框架可以使用JavaServer Pages（包括JSTL和JSF）、Velocity模板、PDF、XSLT和FreeMarker。
除了支持Action和结果外，Struts框架还提供对异常处理程序和拦截器的支持。异常处理程序声明用于定义全局异常和本地异常的异常处理程序。不需要在代码中编写try/catch块，这个框架其实简化了异常处理。框架捕获每个异常后，会显示消息和异常方面相应细节的页面。

拦截器指定了动作的请求处理生命周期。拦截器还指定了在Action类执行前后出现的动作顺序。如前所述，拦截器经配置后，可以把常见功能作用到请求上。该框架的大多数核心功能作为拦截器来实现。如果有些动作响应了Ajax、SOAP或者JSF请求，生命周期就能得到简化，请求也只需通过拦截器传送，不需要任何执行。

Struts 2请求处理流程
这个架构实际上又是如何工作的呢？初始请求先发送到服务器小程序容器（譬如Tomcat），然后通过一系列过滤器传送。如果与Site Mesh插件等其他技术集成，可选的ActionContextCleanUp过滤器就很有用，要是用到这个过滤器，请求先通过它传送。

接着，调用请求的FilterDispatcher，它使用ActionMapper来确定要不要为这个请求调用动作。如果ActionMapper确定应当调用Action，FilterDispatcher就把控制权委托给ActionProxy。

ActionProxy使用了框架配置文件管理器，该管理器通过struts.xml文件来初始化。然后，ActionProxy创建ActionInvocation，它负责实现命令模式。ActionInvocation进程调用所需的拦截器，然后调用Action。一旦该Action执行，ActionInvocation 就负责查寻与struts.xml中映射的Action结果代码相关的合理结果。

然后结果被执行，大多数时候，这会显示用FreeMarker或者Velocity编写的JSP或者模板。按照相反顺序完成Action之后，拦截器再次得到执行。最后，响应通过web.xml中配置的过滤器返回。如果ActionContextCleanUp过滤器经过配置，FilterDispatcher就不会清理ThreadLocal ActionContext（ActionContext拥有运行时请求和响应的全部细节，该框架使用ThreadLocal以及 ActionContext类来提供配置及其他运行时细节）。如果ActionContextCleanUp过滤器未经配置，FilterDispatcher就会清理所有的当前ThreadLocal。图1描述了Struts 2框架的架构。

 

FilterDispatcher，将接收所有请求，并根据ActionMapper（请参考：docs\actionmapper.html）所提供的信息，决定Action是否应该被调用或哪些方法将被调用（如判断其URL扩展名是否符合要求，URL是否符合某些特定的语法规则（如foo!bar.action将调用foo类的bar方法）等，请参考相关的文档），当然，对于ActionMapper而言，由于它的判断需要依赖于struts2的配置，所以，它也要用到 ConfigurationManager来获得配置信息。

接下来，针对每个Action类，将创建ActionProxy对象，它的创建依赖于ConfigurationManager（即配置文件）。

接下来执行ActionProxy对象的execute方法，如果给Action配置了一系列拦截器，那么这个Action的代理类将逐个执行这些拦截器。

当ActionProxy调用Action的方法，执行完之后，它将获得相关的Result对象，并调用Result.的execute方法来产生response对象。

Struts 1与Struts 2的比较
Struts 1和Struts 2有三个共同的基本概念: 请求处理程序、响应处理程序和标签库。不过在Struts 2中，这些部分经过了重新设计，并得到了改进，以便开发。

开发人员会注意到Struts 2框架中出现的许多改动。譬如说，过滤器取代了服务器小程序，相应变化在部署描述文件里会有所体现。同样，配置文件经过了全面改动。还会注意到其他一些关键特性，譬如Action类方面的变化、支持注释、验证方面的变化。表1详细解释了这些变化。

Struts 2.0的新特性
Struts 2.0框架中出现的许多特性旨在让Struts更容易使用:
● 改进的设计: 与Struts 1相比，Struts 2的所有类都基于接口，核心接口独立于HTTP。这些API并不依赖服务器小程序API。

● 简化的Action: Struts 2 Action类独立于框架，是简化的普通Java对象（POJO）。拥有execute()方法的任何Java类都可以用做Action类。

● POJO表单: Struts 2不支持ActionForms特性。ActionForms中定义的属性可以直接放在Action类上。不需要使用所有的String属性。

● 智能默认值: Struts 2配置文件中的大多数配置元素都会有默认值，所以不需要设定值，除非需要不同的值。这有助于减少在XML文件中需要进行的配置。Struts 2支持注释，这带来了更大的方便。

● 改进的结果: 在Struts 2中，
>forward<标签被<result>标签取代。不像 ActionForwards，Struts 2结果可以帮助准备响应，并提供构建多种输出类型的灵活性。

● 改进的标签: Struts 2标签不单单发送输出数据，还能提供样式表驱动标记，这样就可以用较少的代码构建一致性页面。Struts 2标签现在可与FreeMarker、Velocity及类似模板引擎配合使用。

● 引入拦截器: Struts 2为拦截器（interceptor）提供了全面支持。拦截器可在Action类执行前后加以执行。拦截器经配置后，可以把工作流程或者验证等常见功能作用到请求上。所有请求通过一组拦截器传送，之后再发送到Action类。Action类被执行后，请求按照相反顺序再次通过拦截器传送。

● 支持Ajax: 为了创建使用Ajax的动态Web应用，Struts 2提供了Ajax主题，从而大大改进了交互应用。面向Ajax的Struts 2标签基于Dojo窗口组件。还有用于其他框架的插件。

● 快速启动: 部署配置文件可以重新装入; 因而，可以动态地进行许多变化，用不着重新启动Web容器。

● 状态复选框: Struts 2框架可自动跟踪复选框，如果缺少了某复选框，就会采用默认值false。因而，不像在Struts 1中，复选框不需要对false值进行特殊处理。

● 易于测试: Struts 2 Actions独立于HTTP，因而与框架中立。无须使用模拟对象（mock object），就很容易测试。

●使用注释: 使用Struts 2开发的应用可以使用Java 5注释，作为XML和Java属性配置之外的一个替代办法。注释尽量减少了对XML的需要。Action、拦截器、验证及类型转换方面都有注释。

● 易于插入: 只要把插件JAR文件放到\WEB-INF\lib目录中，即可轻松安装Struts 2插件，不需要手动配置。

● 便于与Spring集成: Struts 2 Action能够感知Spring（Spring-aware）。只要为某个应用添加Spring beans，就可以添加对Spring的支持。

● 易于定制的控制器: Struts 1允许请求处理程序可按照模块来定制，在Struts 2中，需要的话，可以按照动作来定制请求处理。

【总结：】
一个请求在Struts2框架中的处理大概分为以下几个步骤

1) 客户端初始化一个指向Servlet容器（例如Tomcat）的请求

2) 这个请求经过一系列的过滤器（Filter）（这些过滤器中有一个叫做ActionContextCleanUp的可选过滤器，这个过滤器对于Struts2和其他框架的集成很有帮助，例如：SiteMesh Plugin）

3) 接着FilterDispatcher被调用，FilterDispatcher询问ActionMapper来决定这个请求是否需要调用某个Action。

4) 如果ActionMapper决定需要调用某个Action，FilterDispatcher把请求的处理交给ActionProxy。

5) ActionProxy通过Configuration Manager询问框架的配置文件，找到需要调用的Action类。

6) ActionProxy创建一个ActionInvocation的实例。

7) ActionInvocation 实例使用命名模式来调用，回调Action的execute方法，该execute方法先获取用户请求参数，然后它会调用业务逻辑组件来处理用户的请求。在调用Action的过程前后，涉及到相关拦截器（Intercepter）的调用。

8) 一旦Action执行完毕，ActionInvocation负责根据struts.xml中的配置找到对应的返回结果。返回结果通常是（但不总是，也可能是另外的一个 Action链）一个需要被表示的JSP或者FreeMarker的模版。在表示的过程中可以使用Struts2 框架中继承的标签。在这个过程中需要涉及到ActionMapper。

在上述过程中所有的对象（Action，Results，Interceptors，等）都是通过ObjectFactory来创建的。

2. Struts 1和Struts 2对比

2.1. 在Action实现类方面的对比：
Struts 1要求Action类继承一个抽象基类；Struts 1的一个具体问题是使用抽象类编程而不是接口。
Struts 2 Action类可以实现一个Action接口，也可以实现其他接口，使可选和定制的服务成为可能。Struts 2提供一个ActionSupport基类去实现常用的接口。即使Action接口不是必须实现的，只有一个包含execute方法的POJO类都可以用作Struts 2的Action。

2.2. 线程模式方面的对比：
Struts 1 Action是单例模式并且必须是线程安全的，因为仅有Action的一个实例来处理所有的请求。单例策略限制了Struts 1 Action能做的事，并且要在开发时特别小心。Action资源必须是线程安全的或同步的；
Struts 2 Action对象为每一个请求产生一个实例，因此没有线程安全问题。

2.3. 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，从而给开发者更多灵活的选择。

2.4. 可测性方面的对比：
测试Struts 1 Action的一个主要问题是execute方法依赖于Servlet API，这使得Action的测试要依赖于Web容器。为了脱离Web容器测试Struts 1的Action，必须借助于第三方扩展：Struts TestCase，该扩展下包含了系列的Mock对象（模拟了HttpServetRequest和HttpServletResponse对象），从而可以脱离Web容器测试Struts 1的Action类。
Struts 2 Action可以通过初始化、设置属性、调用方法来测试。

2.5. 封装请求参数的对比：
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，从而降低了代码污染。

2.6. 表达式语言方面的对比：
Struts 1整合了JSTL，因此可以使用JSTL表达式语言。这种表达式语言有基本对象图遍历，但在对集合和索引属性的支持上则功能不强；
Struts 2可以使用JSTL，但它整合了一种更强大和灵活的表达式语言：OGNL（Object Graph Notation Language），因此，Struts 2下的表达式语言功能更加强大。

2.7. 绑定值到视图的对比：
Struts 1使用标准JSP机制把对象绑定到视图页面；
Struts 2使用“ValueStack”技术，使标签库能够访问值，而不需要把对象和视图页面绑定在一起。

2.8. 类型转换的对比：
Struts 1 ActionForm 属性通常都是String类型。Struts 1使用Commons-Beanutils进行类型转换，每个类一个转换器，转换器是不可配置的；
Struts 2使用OGNL进行类型转换，支持基本数据类型和常用对象之间的转换。

2.9. 数据校验的对比：
Struts 1支持在ActionForm重写validate方法中手动校验，或者通过整合Commons alidator框架来完成数据校验。
Struts 2支持通过重写validate方法进行校验，也支持整合XWork校验框架进行校验。

2.10. Action执行控制的对比：
Struts 1支持每一个模块对应一个请求处理（即生命周期的概念），但是模块中的所有Action必须共享相同的生命周期。
Struts 2支持通过拦截器堆栈（Interceptor Stacks）为每一个Action创建不同的生命周期。开发者可以根据需要创建相应堆栈，从而和不同的Action一起使用。