疯狂java


您现在的位置: 疯狂软件 >> 新闻资讯 >> 正文

Struts1和Struts2的区别和对比


 

   

  Apache Struts(简称Struts)是一种非常流行的Web框架,可用于使用Java企业版(JEE)开发Web应用。Struts项目是负责开发及维护 Struts框架的开源社区。Struts在2001年7月发布,目前已成为使用JEE开发Web应用的事实上的标准。而社区新近发布的Struts 2.0更是一种精致、可扩展的框架,可用于使用Java代码来开发企业就绪的Web应用。该框架旨在简化从构建、部署到日常维护的整个应用开发周期。

  设计Struts框架的目的是为了让开发人员可以构建一种数据库代码、页面设计代码和控制流程代码不混合在一起的服务器小程序或者 JavaServer Pages。因为,要是代码混合在一起,随着应用越来越庞大,就会变得难以维护。Struts框架基于MVC架构,可以帮助开发人员利用明确的关注点分离 (separation of concerns)原则,开发动态Web应用。

  Struts 2请求处理流程

  这个架构实际上又是如何工作的呢?初始请求先发送到服务器小程序容器(譬如Tomcat),然后通过一系列过滤器传送。如果与Site Mesh插件等其他技术集成,可选的ActionContextCleanUp过滤器就很有用,要是用到这个过滤器,请求先通过它传送。

  接着,调用请求的FilterDispatcher,它使用ActionMapper来确定要不要为这个请求调用动作。如果ActionMapper确定应当调用Action,FilterDispatcher就把控制权委托给ActionProxy。

  ActionProxy使 用了框架配置文件管理器,该管理器通过struts.xml文件来初始化。然后,ActionProxy创建ActionInvocation,它负责实 现命令模式。ActionInvocation进程调用所需的拦截器,然后调用Action。一旦该Action执行,ActionInvocation 就负责查寻与struts.xml中映射的Action结果代码相关的合理结果。

  然后结果被执行,大多数时候,这 会显示用FreeMarker或者Velocity编写的JSP或者模板。按照相反顺序完成Action之后,拦截器再次得到执行。最后,响应通过 web.xml中配置的过滤器返回。如果ActionContextCleanUp过滤器经过配置,FilterDispatcher就不会清理 ThreadLocal ActionContext(ActionContext拥有运行时请求和响应的全部细节,该框架使用ThreadLocal以及 ActionContext类来提供配置及其他运行时细节)。如果ActionContextCleanUp过滤器未经配 置,FilterDispatcher就会清理所有的当前ThreadLocal。图1描述了Struts 2框架的架构。

  FilterDispatcher,将接收所有请求,并根据ActionMapper(请参考:docsactionmapper.html)所提供的 信息,决定Action是否应该被调用或哪些方法将被调用(如判断其URL扩展名是否符合要求,URL是否符合某些特定的语法规则(如 foo!bar.action将调用foo类的bar方法)等,请参考相关的文档),当然,对于ActionMapper而言,由于它的判断需要依赖于 struts2的配置,所以,它也要用到 ConfigurationManager来获得配置信息。

  接下来,针对每个Action类,将创建ActionProxy对象,它的创建依赖于ConfigurationManager(即配置文件)。

  接下来执行ActionProxy对象的execute方法,如果给Action配置了一系列拦截器,那么这个Action的代理类将逐个执行这些拦截器。

  当ActionProxy调用Action的方法,执行完之后,它将获得相关的Result对象,并调用Result.的execute方法来产生response对象。

  Action 类:

  • Struts1要求Action类继承一个抽象基类。Struts1的一个普遍问题是使用抽象类编程而不是接口,而struts2的Action是接口。

  • Struts 2 Action类可以实现一个Action接口,也可实现其他接口,使可选和定制的服务成为可能。Struts2提供一个ActionSupport基类去 实现 常用的接口。Action接口不是必须的,任何有execute标识的POJO对象都可以用作Struts2的Action对象。

  线程模式:

  • Struts1 Action是单例模式并且必须是线程安全的,因为仅有Action的一个实例来处理所有的请求。单例策略限制了Struts1 Action能作的事,并且要在开发时特别小心。Action资源必须是线程安全的或同步的。

  • Struts2 Action对象为每一个请求产生一个实例,因此没有线程安全问题。(实际上,servlet容器给每个请求产生许多可丢弃的对象,并且不会导致性能和垃圾回收问题)

  Servlet 依赖:

  • Struts1 Action 依赖于Servlet API ,因为当一个Action被调用时HttpServletRequest 和 HttpServletResponse 被传递给execute方法。

  • Struts 2 Action不依赖于容器,允许Action脱离容器单独被测试。如果需要,Struts2 Action仍然可以访问初始的request和response。但是,其他的元素减少或者消除了直接访问HttpServetRequest 和 HttpServletResponse的必要性。

  可测性:

  • 测试Struts1 Action的一个主要问题是execute方法暴露了servlet API(这使得测试要依赖于容器)。一个第三方扩展--Struts TestCase--提供了一套Struts1的模拟对象(来进行测试)。

  • Struts 2 Action可以通过初始化、设置属性、调用方法来测试,“依赖注入”支持也使测试更容易。

  捕获输入:

  • Struts1 使用ActionForm对象捕获输入。所有的ActionForm必须继承一个基类。因为其他JavaBean不能用作ActionForm,开发者经 常创建多余的类捕获输入。动态Bean(DynaBeans)可以作为创建传统ActionForm的选择,但是,开发者可能是在重新描述(创建)已经存 在的JavaBean(仍然会导致有冗余的javabean)。

  • Struts 2直接使用Action属性作为输入属性,消除了对第二个输入对象的需求。输入属性可能是有自己(子)属性的rich对象类型。Action属性能够通过 web页面上的taglibs访问。Struts2也支持ActionForm模式。rich对象类型,包括业务对象,能够用作输入/输出对象。这种 ModelDriven 特性简化了taglib对POJO输入对象的引用。

  表达式语言:

  • Struts1 整合了JSTL,因此使用JSTL EL。这种EL有基本对象图遍历,但是对集合和索引属性的支持很弱。

  • Struts2可以使用JSTL,但是也支持一个更强大和灵活的表达式语言--"Object Graph Notation Language" (OGNL).

  绑定值到页面(view):

  • Struts 1使用标准JSP机制把对象绑定到页面中来访问。

  • Struts 2 使用 "ValueStack"技术,使taglib能够访问值而不需要把你的页面(view)和对象绑定起来。ValueStack策略允许通过一系列名称相同但类型不同的属性重用页面(view)。

  类型转换:

  • Struts 1 ActionForm 属性通常都是String类型。Struts1使用Commons-Beanutils进行类型转换。每个类一个转换器,对每一个实例来说是不可配置的。

  • Struts2 使用OGNL进行类型转换。提供基本和常用对象的转换器。

  校验:

  • Struts 1支持在ActionForm的validate方法中手动校验,或者通过Commons Validator的扩展来校验。同一个类可以有不同的校验内容,但不能校验子对象。

  • Struts2支持通过validate方法和XWork校验框架来进行校验。XWork校验框架使用为属性类类型定义的校验和内容校验,来支持chain校验子属性

  Action执行的控制:

  • Struts1支持每一个模块有单独的Request Processors(生命周期),但是模块中的所有Action必须共享相同的生命周期。

  • Struts2支持通过拦截器堆栈(Interceptor Stacks)为每一个Action创建不同的生命周期。堆栈能够根据需要和不同的Action一起使用。