Struts1与Struts2本质区别

1 在Action实现类方面的对比：Struts 1要求Action类继承一个抽象基类；Struts 1的一个具体问题是使用抽象类编程而不是接口。Struts 2 Action类可以实现一个Action接口，也可以实现其他接口，使可选和定制的服务成为可能。Struts 2提供一个ActionSupport基类去实现常用的接口。即使Action接口不是必须实现的，只有一个包含execute方法的POJO类都可以用作Struts 2的Action。 2 线程模式方面的对比：Struts 1 Action是单例模式并且必须是线程安全的，因为仅有Action的一个实例来处理所有的请求。单例策略限制了Struts 1 Action能做的事，并且要在开发时特别小心。Action资源必须是线程安全的或同步的；Struts 2 Action对象为每一个请求产生一个实例，因此没有线程安全问题。 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，从而给开发者更多灵活的选择。 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可以通过初始化、设置属性、调用方法来测试。 ### Struts1与Struts2本质区别 #### 1. 在Action实现类方面的对比 - **Struts 1**：要求Action类必须继承一个抽象基类`Action`，这种设计方式意味着开发者必须按照预设的结构来编写代码，灵活性较低。这种通过抽象类而非接口的方式也限制了代码的复用性和扩展性。 - **Struts 2**：提供了一个更加灵活的设计方案，Action类可以选择实现`Action`接口或其他接口。这种方式提高了组件间的解耦合度，使得开发者可以根据实际需求选择最适合的服务接口进行实现。此外，Struts 2还提供了一个`ActionSupport`基类，该类已经实现了常见的接口，进一步减轻了开发者的负担。值得注意的是，在Struts 2中，即使是简单的POJO（Plain Old Java Object）对象，只要包含`execute`方法，就可以作为Action使用。 #### 2. 线程模式方面的对比 - **Struts 1**：Action采用单例模式，这意味着所有请求都将由同一个Action实例处理。为了确保线程安全，开发者必须非常谨慎地管理共享资源和状态，增加了开发复杂度。 - **Struts 2**：每个请求都会创建一个新的Action实例，消除了线程安全问题，同时也减少了开发者在处理并发请求时需要考虑的问题。 #### 3. Servlet依赖方面的对比 - **Struts 1**：Action的方法签名中包含了`HttpServletRequest`和`HttpServletResponse`等Servlet API中的对象，这意味着Action的实现高度依赖于Servlet容器。 - **Struts 2**：通过松耦合的设计，Action不再直接依赖于Servlet API。这不仅简化了Action的编写，也使得Action可以在没有Web容器的情况下独立测试，提高了测试效率和便利性。 #### 4. 可测性方面的对比 - **Struts 1**：由于Action的`execute`方法依赖于Servlet API，所以在进行单元测试时，必须依赖于Web容器环境，增加了测试的复杂度。通常需要借助于第三方工具如Struts TestCase提供的Mock对象来模拟HTTP请求和响应。 - **Struts 2**：Action的测试更加简单直接，只需要初始化Action对象，设置所需的属性，然后调用`execute`方法即可完成测试。这种方式极大地提高了测试的效率和便利性。 #### 5. 封装请求参数的对比 - **Struts 1**：使用`ActionForm`对象来封装用户的请求参数。每个`ActionForm`都需要继承自`ActionForm`基类，并且只能用于特定的Action。这导致了大量的`ActionForm`类需要被创建和维护。 - **Struts 2**：直接使用Action的属性来封装请求参数，简化了参数的处理流程。此外，还提供了`ModelDriven`模式，允许开发者使用单独的模型对象来封装请求参数，进一步增强了代码的可读性和可维护性。 #### 6. 表达式语言方面的对比 - **Struts 1**：整合了JSTL的EL（Expression Language）表达式语言，支持基本的对象图遍历，但对于复杂的集合操作和索引属性的支持有限。 - **Struts 2**：使用更强大的OGNL（Object Graph Notation Language）表达式语言，支持复杂的数据结构操作，如遍历集合、获取嵌套属性等，大大提高了数据访问的灵活性和便利性。 #### 7. 绑定值到视图的对比 - **Struts 1**：使用标准的JSP机制将对象绑定到视图页面。 - **Struts 2**：使用“ValueStack”技术，使标签库可以直接访问值，无需显式地将对象绑定到页面，简化了数据传递的过程。 #### 8. 类型转换的对比 - **Struts 1**：使用`Commons-Beanutils`进行类型转换，但转换器不可配置，缺乏灵活性。 - **Struts 2**：使用OGNL进行类型转换，支持更多的数据类型转换，提高了灵活性。 #### 9. 数据校验的对比 - **Struts 1**：支持在`ActionForm`中重写`validate`方法进行手动校验，也可以整合`Commons-validator`框架进行校验。 - **Struts 2**：支持在Action中重写`validate`方法进行校验，也支持整合`XWork`校验框架进行校验，提供了更多的校验策略。 #### 10. Action执行控制的对比 - **Struts 1**：Action的执行顺序依赖于配置文件中的配置，灵活性较低。 - **Struts 2**：通过拦截器链（Interceptor Chain）来控制Action的执行流程，使得开发者可以根据需要动态调整Action的执行顺序，增强了系统的灵活性和扩展性。