详解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可以通过初始化、设置属性、调用方法来测试。

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一起使用。

 

struts1 
2001年6月发布struts1 
struts1的核心是控制器，由两部分组成：核心控制器和业务逻辑控制器，核心控制器是ActionServlet，由struts1提供；业务逻辑控制是用户自定义的action，由应用开发者提供。 
整个应用由客户端请求驱动，客户端向web发送的请求被struts1的核心控制器ActionServlet拦截，ActionServlet根据请求决定是否调用业务逻辑控制器处理用户请求（事实上，业务逻辑控制器还是控制器，它只是负责调用模型来处理用户请求），当用户请求处理完后，其处理结果通过jsp呈现给用户。 
如果用户只是希望得到某个url资源，得有ActionServlet将被请求的资源转发给用户。 

 
struts1中的mvc： 
1）struts1的model部分主要由底层的业务逻辑组件充当，这些业务逻辑组件封装了底层数据库访问、业务逻辑方法实现。对于一个成熟的企业应用而言，model部分不是一个简单的javabean所能完成的。总之，model部分封装了整个应用的所有业务逻辑，但整个部分并不是struts1提供的，struts1也没有为实现model组件提供任何支持。 
2）struts1的view部分采用jsp实现。提供了标签库，能减少脚本的使用。标签库可以输出控制器的处理结果。 
但struts1锁支持的表现层技术非常单一：既不支持FreeMarker、Velocity等模版技术，也不支持JasperReports等报表技术 
3）struts1的核心控制器ActionServlet继承HttpServlet类，因此可配置为标准的servlet，负责拦截所有的http请求 
业务逻辑控制器负责处理用户请求，但其自身并不具有处理能力，而是调用model来处理请求 
不得不佩服struts1设计者高度解耦的设计：控制器并没有直接转发请求，而仅仅返回一个ActionForward对象（可理解为逻辑视图名）--实际的转发放在配置文件struts-config.xml中进行管理，配置文件中定义了逻辑视图名与视图资源之间的对应关系。当ActionServlet得到处理器返回的ActionForward对象后，根据对应关系，将视图资源呈现给用户。 

struts1的种种缺陷： 
1）支持的表现层技术单一 
struts1只支持jsp作为表现层技术，不提供表现层技术的整合。出现年代太早，当时还没有出现FreeMarker、Velocity等技术 
2）与servlet API严重耦合，难于测试 
因为struts1是在model2的基础上发展起来的，因此它完全是基于Servlet API的，所以在struts1的业务逻辑控制器内，充满了大量的servlet API 
action中的参数，通常web容器负责初始化，HttpServletRequest和HttpServletResponse都是servlet API，严重依赖web服务器，因此，一旦脱离web容器，测试action非常困难。 
Action代码片段： 

//业务逻辑控制器必须继承struts1的Action类
public class LoginAction extends Action
{
 //处理用户请求的execute方法
public ActionForward execute(ActionMapping mapping, ActionForm form,
         HttpServletRequest request, HttpServletResponse response)throws
                AuctionException
{
  //获取封装用户请求参数的ActionForm对象
  //将其强制转换为登陆用的ActionForm
  LoginForm loginForm = (LoginForm)form;
  //当用户名为scott,密码为tiger时，返回成功
  if ("scott".equals(loginForm.getUsername()
   && "tiger".equals(loginForm.getPassword())
  {
   //处理成功，返回一个ActionForward对象
   return mapping.findForward("success");
  }
  else
  {
   //处理失败，返回一个ActionForward对象
   return mapping.findForward("false");
  }
}
}

3）代码严重依赖struts1 API，属于侵入式设计 
struts1的action类必须继承struts1的action基类，实现处理方法时，又包含了大量的struts1 API：ActionMapping、ActionForm、ActionForward。 
这种侵入式设计的最大弱点在于，一旦系统需要重构，这些action类将完全没有利用价值，成为废品。 
可见，struts1的action类的这种侵入式设计 导致了较低的代码复用。 


------------------------------ 
webwork 
采用更加松耦合的设计，系统的action和servlet API不在耦合，使单元测试更方便，允许系统从B/S结构向C/S结构转换 
webwork支持更多的表现层技术，如velocity，freemarker和xslt等 
webwork可以脱离web应用使用，webwork有自己的控制反转（Inversion of Control）容器，通过控制反转，能让测试更简单 
从处理流程上来看，webwork与struts1很相似，核心都是控制器组成： 
1）核心控制器ServletDispatcher，由框架提供 
2）业务逻辑控制器Action，由程序员提供 

 
相对于struts1，webwork优点 
1）action无需与Servlet API耦合，更容易测试 
2）action无需与webwork耦合，代码重用率高 
仅仅实现webwork的action接口，包含了一个execute方法。 
实现一个接口和继承一个类是完全不同的概念，实现一个接口对类的污染小的多，该类可以实现其他任意接口，还可以继承一个父类；但一旦已经继承了一个父类，则意味着该类不能在继承其他父类。 
3）支持更多的表现层技术，有更好的适应性 

---------------- 
struts2 
2006年 

 
struts2的大致处理流程如下： 
1）浏览器发送请求，例如请求/mypage.action、/reports/myreport.pdf 
2）核心控制器FilterDispatcher根据请求决定调用合适的Action 
3）webwork的拦截器链自动对请求应用通用功能，例如：workfolw、validation或文件上传等功能 
4）回调Action的execute方法，该execute方法先获取用户请求参数。实际上，因为Action只是一个控制器，它会调用业务逻辑组件来处理用户的请求 
5）Action的execute方法处理结果信息将被输出到浏览器中，此时支持的视图技术非常多。 


struts2的配置文件有两份： 
1）配置Action的struts.xml文件 
2）配置struts2全局属性的struts.properties 
定义action的处理结果时，可以指定多个result，result元素指定execute方法返回值和试图资源之间的映射关系。 
<result name="cancel" type="redirect-action">Welcome</result> 
定义result元素时，可以指定两个属性：type和name，其中name指定execute方法返回的字符串，type指定转向的资源类型，可以是jsp，也可以是freemarker等，甚至是另一个action，这也是struts2可以支持多种视图技术的原因。 

struts2的控制器组件： 
所有的MVC框架都是以控制器组件为核心，struts2的控制器有两部分组成：FilterDispatcher和业务控制器Action。 
实际上，struts2中起作用的业务控制器不是用户定义的Action，而是系统生成的Action代理，但该Action代理以用户定义的Action为目标。 
通过查看action代码发现，struts2的action比webwork的action更彻底，该action无需实现任何父接口，无需实现任何struts2基类，该action完全是一个POJO（普通、传统的java对象），具有很好的复用性。 
归纳起来，struts2的action具有如下优势： 
1）action类完全是一个pojo，因此具有很好的代码复用性； 
2）action类无需与servlet API耦合，因此进行单元测试非常简单 
3）action类的execute方法就仅返回一个字符串作为处理结果，该处理结果可映射到任何的结果，甚至是另一个action 

------------------------- 
struts1和struts2的简要对比： 
1）action实现类方面的对比：struts1要求action类继承一个抽象基类，是使用抽象类编程而不是接口；struts2 action类可以实现一个action接口，也可以实现其他接口，使可选和定制的服务成为可能。struts2提供一个ActionSupport基类去实现常用的接口。但即使是这个action接口也不是必须实现的，只要是一个包含execute方法的pojo类，都可以用作struts2的action。 
2）线程模版方面的对比：struts1 action是单例模式并且必须是线程安全的，因为仅有action的一个实例来处理所有请求。单例策略限制了struts1 action能做的事，并且要在开发式特别小心。action资源必须是线程安全的；struts2 action为每一个请求产生一个实例，因此没有线程安全问题。 
3）servlet依赖方面的对比：struts1 action依赖servlet API；struts2 action不在依赖于servlet api，从而允许action脱离web容器运行，降低测试难度。 
4）可测性方面的对比：struts1 action的容器，脱离web容器测试struts1 action需要借助于第三方扩展 struts testcase；struts2 action可通过初始化，设置属性，调用方法来测试。 
5）封装请求参数的对比 
6）表达式语言方面的对比：struts1 整合了JSTL ，struts2也可以使用JSTL，而且整合了一种更强大和灵活的表达式语言：OGNL 
7）绑定值到视图的对比：struts1使用标准JSP机制把对象绑定到视图页面；struts2使用“ValueStack”技术，使标签库能访问值，而不需要把对象和视图页面绑定到一起。 
8）类型转换的对比：Stuts1的actionForm的属性通常都是String类型，struts1使用comments-beanutils进行类型转换，每个类一个转换器，转换器是不可配置的；struts2使用OGNL进行类型转换，支持基本数据类型和常用对象之间的转换。 
9）数据校验对比：struts1支持在actionFrom重写validate方法中手动校验，或者通过整合Commons alidator框架来完成数据校验。struts2支持重写validate方法进行校验，也支持整合xwork校验框架进行校验。 
10）action执行控制的对比：struts1支持为每个模块对应一个请求（即生命周期的概念），但模块中的所有action必须共享相同的生命周期。struts2支持通过连接器堆栈（Interceptor Stacks）为每个action创建不同的生命周期。 

------------------- 
webwork和struts2对比： 

 

struts2不在支持内建的ioc容器，而改为全面支持spring的ioc容器，以spring的ioc容器作为默认的object工厂。