struts1 和 struts2 区别

The_Well

于 2012-07-10 15:13:34 发布

阅读量525

点赞数

分类专栏： java 文章标签： struts webwork action interceptor 框架 spring

java 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

Struts作为MVC 2的Web框架，自推出以来不断受到开发者的追捧，得到广泛的应用。作为最成功的Web框架，Struts自然拥有众多的优点：MVC 2模型的使用、功能齐全的标签库（Tag Library）、开放源代码。但是，正所谓“没有最好，只有更好”，Struts1.x自身也有不少的缺点：需要编写的代码过多，容易引起“类爆炸”、单元测试困难。这些缺点随着Web的发展越来越明显。这就促生了Struts 2，它的诞生能很好的解决上述问题。在本文中，笔者将对Struts2和Struts1.x这两种框架进行详细的比较。比较将涉及到这两种框架的Action、验证、类型转换及如何开发等方面的内容。希望通过这样的比较，让读者了解这两种框架各自的特点，以便于在自己的项目中，根据实际情况，尽快的过渡到Struts2的时代。本文的内容基于Struts2.0.6。一、       引言Struts的第一个版本是在2001年5月份发布的。它的最初设想是通过结合JSP和Servlet，使Web应用的视图和业务/应用逻辑得以清晰地分离开来。在Struts之前，最常见的做法是在JSP中加入业务和应用逻辑，或者在Servlet中通过println()来生成视图。自从第一版发布以来，Struts实际上已成为业界公认的Web应用标准。它的炙手可热也为自己带来了改进和变更，所以不但要跟上对Web应用框架不断变化的需求，而且要与日渐增多竞争激烈的众多框架的特性相融合。到最后，产生了几个下一代Struts的解决方案。其中两个最受瞩目的方案是Shale和Struts Ti。Shale是一个基于构件的框架，并在最近成为Apache的顶级项目。而Struts Ti则是在Struts的成功经验基础上继续坚持对前端控制器（Front Controller）和MVC（model-view-controller）模式进行改进。WebWork项目是在2002年3月发布的，它对Struts式框架进行了革命性改进，引进了不少新的思想、概念和功能，但和原Struts代码并不兼容。WebWork是一个成熟的框架，经过了好几次重大的改进与发布。在2005年12月，WebWork与Struts Ti宣布合并。与此同时，Struts Ti改名为Struts Action Framework 2.0，成为Struts真正的继承者。最后要注意的是，并不是说Struts或WebWork项目已经停止开发了。由于人们对这两个项目的兴趣仍然很高，而且也有很多开发者仍然愿意使用它们，因此这两个项目还在继续开发中，继续修复Bug，改进功能和继续添加新功能。

二、 Action的区别对于有着丰富的Struts1.x开发经验的朋友来说，都十分的清楚Action是整个Struts框架的核心内容，当然Struts2也不例外。不过，Struts1.x与Struts2的Action模型很大的区别。Struts2和Struts1.x的差别，最明显的 就是Struts2是一个pull-MVC架构。这是什么意思呢？从开发者角度看，就是说需要显示给用户的数据可以直接从Action中获取，而不像 Struts1.x那样，必须把相应的Bean存到Page、Request或者Session中才能获取。Struts1.x 必须继承org.apache.struts.action.Action或者其子类，表单数据封装在FormBean中。Struts 2无须继承任何类型或实现任何接口，表单数据包含在Action中，通过Getter和Setter获取（如下面的ActionForStruts2的代码示例）。
虽然，在理论上Struts2的Action无须实现任何接口或者是继承任何的类，但是，在实际编程过程中，为了更加方便的实现Action，大多数情况下都会继承com.opensymphony.xwork2.ActionSupport类，并且重载（Override）此类里的String execute()方法。

首先，从ActionForStruts2可以看出，返回的对象不是ActionForward，而是String。如果你不喜欢以字符串的形式出现在你的代码中，有个Helper接口Action可以以常量方式提供常见结果，如“success”、“none”、“error”、“input”和“login”。另外，按照惯例，在Struts1.x中只有“execute”方法能调用Action, 但在Struts2中并非必要，任何声明为public String methodName() 方法，都能通过配置来调用Action。最后，和Struts1.x最大的革命性的不同是，Struts2处理Action过程中调用的方法（“execute”方法）是不带参数的。那如何获取所需要的对象呢？答案是使用IoC（反转控制，Inversion of Control)，也叫“依赖注入（Dependency Injection）”的模式（想更多地了解这方面信息请看Martin Fowler的文章http://www.martinfowler.com/articles/injection.html）。Spring框架使得这个模式流行起来，然而Struts2的前身（WebWork）也同时应用上了这个模式。

三、     IoCIoC(Inversion of Control，以下译为控制反转），随着Java社区中轻量级容器（Lightweight Contianer）的推广而越来越为大家耳熟能详。在此，无需再多费唇舌来解释“什么是控制反转”和“为什么需要控制反转”。因为互联网上已经有非常多的文章对诸如此类的问题作了精彩而准确的回答。读者可以去读一下Rod Johnson和Juergen Hoeller合著的《Expert one-on-one J2EE Development without EJB》或Martin Fowler所写的《Inversion of Control Containers and the Dependency Injection pattern》。
众所周知，Struts2是以Webwork 2作为基础发展出来。而在Webwork 2.2之前的Webwork版本，其自身有一套控制反转的实现，Webwork 2.2在Spring 框架的如火如荼发展的背景下，决定放弃控制反转功能的开发，转由Spring实现。值得一提的是，Spring确实是一个值得学习的框架，因为有越来越多的开源组件（如iBATIS等）都放弃与Spring重叠的功能的开发。因此，Struts2推荐大家通过Spring实现控制反转。
为了更好地了解反转控制，下面来看一个例子，如何利用IoC在Action处理过程中可以访问到当前请求HttpServerRequest对象。
在例子中，使用的依赖注入机制是接口注入。就如其名称一样，接口注入需要的是已经被实现了的接口。这个接口包含了相应属性的setter，为Action提供值。例子中使用了ServletRequestAware接口，如下：public interface ServletRequestAware {
    public void setServletRequest(HttpServletRequest request);
}当继承这个接口后，原本简单的Action看起来有点复杂了，但是这时可以获取HttpServerRequest对象来使用了。public class IoCForStruts2 implements ServletRequestAware {
   private HttpServletRequest request;
   public void setServletRequest(HttpServletRequest request) {
        this.request = request;
   }
   public String execute() throws Exception {
        // 可以开始使用request对象进行工作了
        return Action.SUCCESS;
   }
}
看起来现在这些属性是类级别的，并不是线程安全的，会出现问题。其实在Struts2里并没有问题，因为每个请求过来的时候都会产生一个新的Action对象实例，它并没有和其他请求共享一个对象，所以不需要考虑线程安全问题。
拦截器 Interceptor（以下译为拦截器），在AOP（Aspect-Oriented Programming）中用于在某个方法或字段被访问之前，进行拦截然后在之前或之后加入某些操作。拦截是AOP的一种实现策略。
在Webwork的中文文档的解释为——拦截器是动态拦截Action调用的对象。它提供了一种机制可以使开发者定义在一个action执行的前后执行的代码，也可以在一个action执行前阻止其执行。同时也提供了一种可以提取action中可重用的部分的方式。
Struts1.x的标准框架中不提供任何形式的拦截器，虽一个名为SAIF的附加项目则实现了这样的功能，但它的适用的范围还很有限。
拦截器是Struts2的一个强有力的工具，有许多功能（feature）都是构建于它之上，如国际化、转换器，校验等。谈到拦截器，还有一个流行的词——拦截器链（Interceptor Chain，在Struts2中称为拦截器栈Interceptor Stack）。拦截器链就是将拦截器按一定的顺序联结成一条链。在访问被拦截的方法或字段时，拦截器链中的拦截器就会按其之前定义的顺序被调用。
Struts 2的拦截器实现相对比较简单。当请求到达Struts2的ServletDispatcher时，Struts 2会查找配置文件，并根据其配置实例化相对的拦截器对象，然后串成一个列表（list），最后一一地调用列表中的拦截器，
Struts 2已经提供丰富多样功能齐全的拦截器实现。读者可以到struts2-all-2.0.6.jar或struts2-core-2.0.6.jar包的struts-default.xml查看关于默认的拦截器与拦截器链的配置。作为“框架（framework）”，可扩展性是不可缺少的，因为世上没有放之四海而皆准的东西。虽然，Struts 2为我们提供如此丰富的拦截器实现，但是这并不意味我们失去创建自定义拦截器的能力，恰恰相反，在Struts 2自定义拦截器是相当容易的一件事。
前面已经简要介绍了 Struts2的起源，并详细对比了Struts2和Struts1.x的差异，读者应该对Struts2的基础有所了解了——包括高层的框架概念和基础 的请求流程，并理解Struts1.x和Struts2两者之间在Action方面的差别，Struts2加强了对拦截器与IoC的支持，而在 Struts1.x中，这些特性是很难想象的。
同时，读者应该明白： Struts2是WebWork的升级，而不是Struts 1.x的升级。虽然Struts 2提供了与Struts1.x的兼容，但已经不是Struts1.x的升级。对于已有Struts1.x开发经验的开发者而言，Struts1.x的开发 经验对于Struts2并没有太大的帮助；相反，对于已经有WebWork开发经验的开发者而言，WebWork的开发经验对Struts2的开发将有很 好的借鉴意义。

问题简单点，就是几个方面：
    1 Action类：Struts1 继承一个抽象基类，Struts2就自由点，只要有 execut方法的Pojo对象就能当action使用，当然也可以继承一些接口和基类。
    2线程：Struts1 action是单例模式而且必须是线程安全的。Struts2 action为每一个请求产生一个实例，所以没有线程安全问题。
    3 依赖：Struts1 Action依赖servletAPI，Struts2不依赖，因为Struts2 的Action就是一个普通的java类。
   4 封装请求：Struts1用扩展ActonForm的类来捕获页面请求参数，ActonFrom是纯粹的Vojo，这使开发者往往还要自行创建一个javaBean来封装这些参数用来作为持久或其它用途，重复的描述一个内容。Struts2可以在Acton里设置相应的属性，也可以支持ActionForm这种模式，用模型驱动（ModelDriven）的特性简化了标签对POJO输入对象的引用。
   5 表达式语言：Struts1 整合了jstl，Struts2不仅可以使用jstl，还整合了OGNL，因此表达式语言功能更强大。
   6 传值到视图：Struts1使用标准jsp机制绑定对象到页面上下文，Struts2使用ValueStack技术，访问更灵活。
   7 类型转换：Struts1 使用Commons-Beanutils进行类型转换，转换每一个类，而不能为每一个实例配置。 Struts2使用ONGL进行类型转换，支持基本数据类型和常用对象之间的转换。
   8数据校验：Struts1支持ActionForm重写validate手动校验，或通过CommonsValidator扩展校验，同一个类可以有不同的校验内容，但不能校验子对象。Struts2 支持重写validate，也支持XWork校验框架进行校验。
  9 Action执行控制： Struts1支持每一个模块有单独的生命周期，但是模块中所有的Action必须享有相同的生命周期。 Struts2 支持拦截器栈为每一个Action创建不同的生命周期。