关于struts1、webwork、struts2 比较 优点 缺点

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代码片段： 
Java代码

• //业务逻辑控制器必须继承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"); 
   } 
  }
  }

  
  
• //业务逻辑控制器必须继承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工厂。