Struts的那些东东

【转载】

 

1.Struts1和Struts2的比较

Action 类 
Struts1.x要求 Action类要扩展自一个抽象基类。 Struts1.x的一个共有的问题是面向抽象类编程而不是面向
接口编程。 
Struts2的Action类实现了一个Action接口，连同其他接口一起来实现可选择和自定义的服务。Struts2提
供一个名叫ActionSupport 的基类来实现一般使用的接口。 当然， Action接口不是必须的。 任何使用execute
方法的POJO对象可以被当作Struts 2的Action对象来使用。

 

线程模型 
Struts1.x Action类是单例类，因为只有一个实例来控制所有的请求。单例类策略造成了一定的限制，并且
给开发带来了额外的烦恼。Action资源必须是线程安全或者同步的。 
Struts2 Action对象为每一个请求都实例化对象，所以没有线程安全的问题。 （实践中，servlet容器给每一

个请求产生许多丟弃的对象，并且不会导致性能和垃圾回收问题） 。

 

Servlet 依赖 
Struts1.x 的 Action 类依赖于 Servlet API ，当 Action 被调用时，以 HttpServletRequest 和
HttpServletResponse作为参数传给execute方法。 
Struts2 的 Action 和容器无关。Servlet 上下文被表现为简单的 Maps，允许 Action 被独立的测试。Struts2
的 Action 可以访问最初的请求(如果需要的话)。但是，尽可能避免或排除其他元素直接访问
HttpServletRequest 或HttpServletResponse。

 

易测性 
测试Struts1.x的主要问题是execute方法暴露了Servlet API这使得测试要依赖于容器） 。第三方的扩展，
如Struts TestCase，提供了一套Struts1的模拟对象（来进行测试） 。 
Struts2的Action可以通过初始化、设置属性、调用方法来测试。依赖注入的支持也是测试变得更简单。
 
捕获输入 
Struts1.x使用 ActionForm对象来捕获输入。象Action一样，所有的ActionForm必须扩展基类。因为其他
的 JavaBean 不能作为 ActionForm 使用，开发者经常创建多余的类来捕获输入。DynaBeans 可以被用来
作为替代 ActionForm 的类来创建。但是，开发者可能是在重新描述(创建)已经存在的 JavaBean（仍然会
导致有冗余的javabean） 。 
Struts2直接使用Action属性作为输入属性，消除了对第二个输入对象的需求。输入属性可能是有自己(子)
属性的rich对象类型。Action属性能够通过 web页面上的taglibs访问。Struts2也支持ActionForm 模式。
rich对象类型，包括业务对象，能够用作输入/输出对象。这种ModelDriven 特性简化了taglib 对POJO输
入对象的引用。 
 
表达式语言 
Struts1.x整合 JSTL，所以它使用JSTL的表达式语言。表达式语言有基本的图形对象移动，但是对集合和
索引属性的支持很弱。 
Struts2 使用 JSTL，但是也支持一个更强大和灵活的表达式语言－－"Object Graph Notation Language"
(OGNL)。 
 
将值绑定到页面 
Struts1.x使用标准JSP机制来绑定对象到页面上下文。 
Struts2 使用“ValueStack”技术，使 taglib 能够访问值而不需要把你的页面（view）和对象绑定起来。
ValueStack策略允许通过一系列名称相同但类型不同的属性重用页面（view） 。 
 
类型转换 
Struts1.x的ActionForm属性经常都是String。Struts 1.x使用Commons-Beanutils来进行类型转换。转换
每一个类，而不是为每一个实例配置。 
Struts2使用OGNL进行类型转换。提供基本和常用对象的转换器。 
 
验证 
Struts1.x支持在 ActionForm 的 validate 方法中手动校验，或者通过 Commons Validator 的扩展来校验。
同一个类可以有不同的校验内容，但不能校验子对象。 
Struts2 支持通过 validate 方法和 XWork 校验框架来进行校验。XWork 校验框架使用为属性类类型定义的

校验和内容校验，来支持chain校验子属性 
 
Action 执行控制 
Struts1.x支持每一个模块有单独的Request Processors（生命周期） ，但是模块中的所有Action必须共享
相同的生命周期。 
Struts2支持通过拦截器堆栈（Interceptor Stacks）为每一个Action创建不同的生命周期。堆栈能够根据需
要和不同的Action一起使用。

 

 

2.Struts2的使用

运行 Struts 2 需要下列的条件：Servlet API 2.4，JSP API 2.0，Java 5（或者使用 j4
版本，运行于 JDK1.4） 。当然换句话说用 Tomcat 5 或者更高版本就没有任何问题了。
 Struts 2 的执行流程大致如此所示：Web 服务器启动解析 struts.xml，初始化消息文件，
Action 路径映射等资源，初始化框架→用户请求 XXX.action →Struts 2 过滤器使用对象工
厂(Object Factory，可以是自带或者是 Spring)创建 Action 类的示例 →执行 IOC和拦截器
（包括解析表单参数，文件上传，将解析结果注入 Action 对象） →调用 Action 中用户编
写的业务方法 →根据返回的结果(Result)路径转向视图层 →视图层进行显示（包括调用标
签库等） 。
  关于其底层结构，从网上搜集到的一些资料认为：WebWork 2，实际上是 Webwork +
XWork 的总集，Webwork1.x 版本中，整个框架采用了紧耦合的设计（类似 Struts 1.x） ，
而 WebWork 2.0 之后，Webwork 被拆分为两个部分，即 Webwork 2.x +XWork 2.x。当
一个请求发起后，从请求的路径名中解析出对应的 Action 名称，然后 Webwork 2.x框架会
遍历 HttpServletRequest、HttpSession、ServletContext 中的数据，并将其复制到内部的
Map 实现中，至此之后，所有数据操作均在此 Map 结构中进行，从而将内部数据结构与
Servlet API 相分离。至此，Webwork 的工作阶段结束，数据将传递给 XWork 进行下一步
处理。从这里也可以看到 Webwork 和 XWork 之间的切分点，Webwork 为 XWork 提供
了一个面向 Servlet 的协议转换器， 将 Servlet 相关的数据转构转换成 XWork 所需要的通
用数据格式，而 XWork将完成实际的服务调度和功能实现。这样一来，以 XWork 为核心，
只需替换外围的协议转换组件，即可实现不同技术平台之间的切换。那么 Struts 2 呢，就是
这样一个 Struts 2核心平台＋XWork 的实现， 其中的 XWork 部分执行和 Servlet API 无关的
流程处理，而 Struts 2的核心层则提供将 Servlet 层提供的数据进行独立封装的过程，进而
XWork 基于这些数据进行操作，这样就实现了一个完整的开发框架。XWork 相当于一个插
件一样和现有框架组合，构成一个完整的流程处理＋Servlet 操纵框架。所以大家会奇怪的
看到 Struts 2 一共有两个核心 jar 文件：struts2-core-2.0.11.jar 和 xwork-2.0.4.jar，而且更
让人奇怪的是前一个文件中的包定义是 org.apache.struts2，而后一个文件中的则是
com.opensymphony.xwork2，其原因就在于此。