对比指标 | Struts1 | Struts2 |
Action类 | Struts1要求Action类继承一个抽象类，Struts1普遍使用抽象类而不是接口 | Struts2 Action类可以实现一个Action接口，也可以实现其他的接口，使可选和定制的服务成为可能，Struts2提供了一个ActionSupport基类去实现常用的接口，Action接口不是必须的，任何有execute表识的POJO对象都可以用做struts2的Action对象 |
线程模式 | Struts1 Action是单例模式并且必须是线程安全的，因为只有一个Action的实例来处理所有的请求，单例策略限制了Struts1 Action能做的事情，并且要在开发时特别小心，Action资源必须是线程安全的 | Struts2 Action对象为每一个请求产生一个实例，因此没有线程安全的问题，实际上，Servlet容器给每个请求产生许多可丢弃的对象，并且不会导致性能和垃圾回收问题 |
Servlet依赖 | Struts1 Action依赖于Servlet API，因为当一个Action被调用时HTTPServletRequest和HTTPServletResponse被传递给execute方法 | Struts2 Action不依赖于容器，允许Action脱离容器单独被测试，如果需要，Struts2 Action仍然可以访问初始的request和response，但是，其他的元素较少或者消除了直接访问HTTPServletRequest和HTTPServletResponse的必要性 |
可测性
| 测试Struts1 Action的一个主要问题是execute方法暴露了Servlet API（这使得测试要依赖于容器），一个第三方扩展Struts TestCase提供了一套Struts 1的模拟对象用于进行测试 | Struts2 Action可以通过初始化、设置属性、调用方法来测试，“依赖注入”支持也使得测试更容易 |
捕获输入 | Struts1 使用ActionForm对象捕获输入，所有的ActionForm必须继承一个基类，因为其他JavaBean不能用作ActionForm，开发者经常创建多余的类捕获输入，动态Bean（DynaBeans）可以作为创建传统ActionForm的选择，但是，开发者可能是在重新描述（创建）已经存在的JavaBean（仍然会导致冗余的JavaBean） | Struts2直接使用Action属性来作为输入属性，消除了对第二个输入对象的需求，输入属性可能是有自己（子）属性的rich对象类型，Action属性能够通过Web页面上的taglibs访问，Struts2也支持ActionForm模式，rich对象类型包括业务对象，能够用做输入/输出对象。这种ModelDriven特性简化了taglib对POJO输入对象的引用 |
表达式语言 | Struts1整合了JSTL，因此使用JSTL，这种EL有基本对象图遍历，但是对集合和索引属性的支持很弱 | Struts2可以使用JSTL，但是支持一个更强大和灵活的表达式语言-“Object Graph Notation Language”（OGNL） |
绑定值到页面 | Struts1 使用标准的JSP机制把对象绑定到页面中来进行访问 | Struts2使用”ValueStack”技术，使taglib能够访问值而不需要把页面（view）和对象绑定起来，ValueStack策略允许通过一系列名称相同但类型不同的属性重用页面 |
类型转换 | Struts1 ActionForm属性通常都是String类型，Struts1使用Commons-Beanutils进行类型转换，每个类一个转换器，对每一个实例来说是不可配置的 | Struts2使用OGNL进行类型转换，提供基本和常用对象的转换器 |
校验 | Struts1支持在ActionForm的validate方法中手动校验，或者通过Commons Validator的扩展来校验，同一个类可以有不同的校验内容，但不能校验子对象 | Struts2支持通过validate方法和XWork校验框架来进行校验，XWork校验框架使用为属性类型定义的校验和内容校验，来支持chain校验子属性 |
Action执行的控制 | Struts1支持每一个模块有单独的Request Process（生命周期），但是模块中的所有Action必须共享相同的生命周期 | Struts2支持通过拦截器堆栈（Interceptor Stacks）为每一个Action创建不同的生命周期，堆栈能够根据需要与不同的Action一起使用 |
