### Struts1与Struts2的主要区别
#### 1. Action类的设计差异
- **Struts1**: 在Struts1框架中，Action类必须继承自一个抽象类`org.apache.struts.action.Action`。这种方式可能导致的问题是代码灵活性较低，尤其是对于那些希望使用其他设计模式或框架的开发者来说。此外，由于Action类的强制继承关系，可能会增加代码维护的复杂度。
- **Struts2**: 相比之下，Struts2提供了更多的灵活性。Action类可以选择实现一个接口`com.opensymphony.xwork2.Action`，也可以实现其他自定义接口。Struts2还提供了一个基础类`com.opensymphony.xwork2.ActionSupport`，该类实现了常用的接口，简化了开发过程。值得注意的是，在Struts2中，Action接口并不是必需的，任何包含`execute`标记的POJO（Plain Old Java Object）对象都可以作为Action对象使用。
#### 2. 线程安全模式的不同
- **Struts1**: Struts1中的Action采用单例模式，因此必须确保线程安全性。这意味着开发者需要特别注意Action类中的资源管理，确保其线程安全或进行适当的同步操作。
- **Struts2**: 在Struts2中，为每个HTTP请求创建一个新的Action实例，从而避免了线程安全问题。这一改变极大地简化了代码编写，并降低了出错的可能性。尽管servlet容器会为每个请求创建多个临时对象，但并不会对性能或垃圾回收造成负面影响。
#### 3. Servlet API的依赖性
- **Struts1**: Struts1的Action类依赖于servlet API，这意味着在执行Action方法时，必须传递`HttpServletRequest`和`HttpServletResponse`参数。这种方式增加了测试的难度，因为测试过程中往往需要模拟这些servlet API组件。
- **Struts2**: Struts2的Action不再直接依赖于容器，这意味着可以独立于容器进行单元测试。虽然Struts2的Action仍然可以访问原始的请求和响应对象，但在大多数情况下，开发者可以利用Struts2提供的其他功能来替代直接访问`HttpServletRequest`和`HttpServletResponse`的需求。
#### 4. 可测试性的提升
- **Struts1**: 测试Struts1的Action主要难点在于其`execute`方法暴露了servlet API，这使得测试依赖于容器环境。为了解决这一问题，社区开发了第三方工具如Struts TestCase，它提供了一套用于模拟Struts1环境的组件。
- **Struts2**: 在Struts2中，可以通过初始化、设置属性和调用方法等方式轻松地测试Action。依赖注入的支持进一步简化了测试过程，使开发者能够更加专注于逻辑验证而非环境配置。
#### 5. 输入数据的处理方式
- **Struts1**: Struts1使用`ActionForm`对象来捕获输入数据，所有`ActionForm`对象必须继承自基类。这种设计模式可能会导致代码冗余，因为开发者需要为每种类型的输入数据创建额外的类。
- **Struts2**: Struts2直接使用Action对象的属性作为输入数据，消除了对`ActionForm`对象的需求。输入数据可以是复杂的对象类型，包含子属性。此外，Struts2支持模型驱动特性，允许使用现有的业务对象作为输入/输出对象，减少了代码冗余并提高了代码复用性。
#### 6. 表达式语言的改进
- **Struts1**: Struts1集成了JSTL，使用JSTL的表达式语言（EL），支持基本的对象图遍历，但对于集合和索引属性的支持较弱。
- **Struts2**: Struts2不仅支持JSTL，还可以使用更强大、更灵活的表达式语言OGNL（Object Graph Navigation Language）。OGNL提供了更丰富的功能，例如支持复杂的对象结构导航以及更强大的数据处理能力。
#### 7. 页面视图的数据绑定
- **Struts1**: 使用标准JSP机制将对象绑定到页面中进行访问。
- **Struts2**: 采用“ValueStack”技术，允许标签库访问值而无需显式绑定视图与对象。这种策略使得视图可以重用，即使它们引用的是不同类型的属性。
#### 8. 类型转换的能力
- **Struts1**: Struts1通常将`ActionForm`属性设为字符串类型，并使用Commons-beanutils进行类型转换。这种方法对每个类都需要一个转换器，并且对每个实例来说是不可配置的。
- **Struts2**: 使用OGNL进行类型转换，为基本和常用对象提供了转换器。Struts2的类型转换机制更为灵活且易于配置。
#### 9. 数据校验机制
- **Struts1**: 支持在`ActionForm`的`validate`方法中手动校验数据，或者通过Commons Validator进行校验。但同一类的不同实例无法拥有不同的校验规则，并且不支持子对象的校验。
- **Struts2**: 提供了多种校验机制，包括通过`validate`方法和XWork校验框架进行校验。XWork框架支持属性级别的校验以及链式校验子属性，增强了灵活性和扩展性。
#### 10. Action执行流程的控制
- **Struts1**: 支持为每个模块单独配置Request Processors（即生命周期管理器），但模块内的所有Action必须共享相同的生命周期。
- **Struts2**: 通过配置拦截器堆栈（Interceptor Stacks）来为每个Action定制不同的执行流程。这种机制使得开发者可以根据具体需求灵活地组合和调整拦截器，实现了更细粒度的控制。
Struts2相比Struts1在灵活性、可测试性、输入数据处理、表达式语言等方面都有显著改进。这些变化不仅简化了开发过程，也提升了应用程序的整体性能和稳定性。
