Struts1和Struts2的区别

       网上看了很多博客写的struts1和struts2的区别，感觉不是很直观通俗。我也来写个版本(因为闲的蛋疼)

一、Struts 2的前世今生。
      Struts 2是webwork的升级，而并不是struts1.x的升级。

 

二、Struts 1的特点
      Struts 1以ActionServlet作为核心控制器，由ActionServlet负责拦截用户的所有请求。
Struts 1框架有3个重要组成部分：Action、ActionForm和ActionForward对象。
Struts 1的Action类与Struts2的Action类有一定的类似性，都通过调用execute方法来处理用户请求。
但最大的区别在于Struts 1 Action的execute方法与Servlet API耦合(ActionServlet继承自HttpServlet)，
但Struts 2 Action类的execute方法无需与Servlet API耦合。
ActionForm必须实现ActionForm的基类,设计上并不是真正的POJO
ActionForward是一个逻辑视图，通过在配置文件中定义ActionFoward的映射，完成逻辑视图名和实际视图资源之间的映射。

      Struts 1的缺陷:
  (1).只支持JSP作为表现层技术,没有什么可选择的。
  (2).与Servlet API严重耦合,难于测试一个exute有四个参数ActionMapping、ActionForm、HttpServletRequest和HttpServletResponse,初始化困难。
  (3).侵入式设计,严重依赖于Struts 1 API,如ActionMapping、ActionForm和ActionForward类.一旦系统需要重构时,这些类完全没有利用价值,代码复用性很低。

 

三、Struts 2的特点
      Struts 2以FilterDispatcher作为核心控制器，该控制器作为一个Filter运行在Web应用中，它负责拦截用户的所有请求，
当用户请求到达时，该Filter会过滤用户请求。如果用户请求以action结尾，该请求将被转入Struts2框架处理。
   Struts 2用于处理用户请求的Action实例，并不是用户实现的业务控制器，而是Action代理——因为用户实现的业务控制器
并没有与Servlet API耦合，显然无法处理用户请求。而Struts 2框架提供了系列拦截器，该系列拦截器负责
将HttpServletRequest请求中的请求参数解析出来，传入到Action中，并回调Action的execute方法来处理用户请求。
显然，上面的处理过程是典型的AOP（面向切面编程）处理方式。

      Struts 2 的优势：
   (1).Strtus 2 Action类完全是一个POJO，因此具有很好的代码复用性。
   (2).Strtus 2 Action类无需与Servlet API耦合，因此进行单元测试非常简单。
   (3).Strtus 2 Action类的execute方法仅返回一个字符串作为处理结果，该处理结果可映射到任何的视图，甚至是另一个Action。
   (4).Strtus 2支持多视图,如:Jsp,Velocity,FreeMarker,JasperReports等。
   (5).Struts 2提供很多丰富的强大的拦截器。

 

    Struts 2 性能问题：
    很多人使用Struts 2后觉得Struts 2比较慢，本人没有做过大型项目，性能慢对我来说没什么感觉。
    分析性能慢的原因：因为struts2的Action对象是Prototype类型的，而且分离Servelt API时大量的用到Java的反射机制，Java的发射恰恰又是非常影响性能。
    对网上的如何提到Struts 2进行了下总结
      (1).不要使用Struts 2的标签，直接用JSTL+EL就可以了。
      (2).关闭logging和devMode.
      (3).不要使用OGNL表达式.
      (4).不要使用你不需要的拦截器，如果一个Action不需要全栈的拦截器的话，就使用basicStack拦截器或移除不需要的拦截器。
 
四、Struts 1与Struts 2的比较:
(1).在Action实现类方面的对比：Struts1要求Action类继承一个抽象基类；Struts1的一个具体问题是使用抽象类编程而不是接口。
    Struts2 Action类可以实现一个Action接口，也可以实现其他接口，使可选和定制的服务成为可能。Struts2提供一个ActionSupport基类去实现常用的接口。
    即使Action接口不是必须实现的，只有一个包含execute方法的POJO类都可以用作Struts2的Action。

(2).线程模式方面的对比：Struts 1 Action是单例模式并且必须是线程安全的，因为仅有Action的一个实例来处理所有的请求。
    单例策略限制了Struts 1 Action能做的事，并且要在开发时特别小心。Action资源必须是线程安全的或同步的；
    Struts2 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可以通过初始化、设置属性、调用方法来测试。

(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，从而降低了代码污染。

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

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

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

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

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