struts2.0新特性以及和struts1.2的区别

Struts2.0

Struts自推出以来不断受到开发者的追捧,其最新版本Struts 2.0亦代表了下一代Java Web开发的新趋势。Struts 2.0框架具有一系列丰富的特性,对大型开发社区很有帮助,而且,从Struts 1迁移到Struts 2也不是很困难。

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框架提供了自己的Web控制器组件来处理控制流程 逻辑。至于视图,它集成了其他技术,譬如JavaServer Pages(包括JSTL和JSF)、Velocity模板引擎和XSLT。至于模型,它使用JDBC、 EJB、Hibernate或者iBATIS等技术来访问数据。


Struts 1.0非常成熟,因此得到众多开发社区的有力支持,而且说明文档内容完备。不过在过去的几年里,许多开源社区的Web框架纷纷登台亮相,所以它需要跟上 Web应用需求不断变化的形势,这就有必要构建下一代Struts框架。力求满足这个要求的初始提案是Struts Ti,这种简化的MVC Model 2框架可用于让需要更少配置、更好结构和控制器特性的人开发Web应用。人们考虑用来实现这个目的的另一个框架是Apache Shale,不过,Shale是基于组件的一种框架,它立足于JSF。Shale开发社区不愿与Struts联合,决定继续把Shale作为一个顶级项目来开发。


WebWork项目由Open Symphony社区启动,面向Struts开发社区。它旨在满足那些希望寻求类似Struts的一种框架,但有更好特性的人的需要。WebWork框架于2002年发布。独立运作了几年后, WebWork和Struts两个社区在2005年12月联合起来,开发了新版本的Struts,即Struts 2。Struts 2实际上就是Struts 1与WebWork的结合体。Struts的这个新版本更易使用,更接近Struts框架的最初版本。

 


基于MVC架构的Struts 2
如前所述,Struts框架基于MVC架构。Struts 2具有一种灵活的控制层,基于Java过滤器、JavaBean、 ResourceBundle、Locale和XML等诸多标准技术上,还基于OGNL和XWork等各种Open Symphony包。
至于模型,该框架可与JDBC、EJB及其他框架(包括Hibernate、iBATIS和Cayenne)等标准的数据访问技术相互联系。至于视图,该框架可以使用JavaServer Pages(包括JSTL和JSF)、Velocity模板、PDF、XSLT和FreeMarker。
除了支持Action和结果外,Struts框架还提供对异常处理程序和拦截器的支持。异常处理程序声明用于定义全局异常和本地异常的异常处理程序。不需要在代码中编写try/catch块,这个框架其实简化了异常处理。框架捕获每个异常后,会显示消息和异常方面相应细节的页面。


拦截器指定了动作的请求处理生命周期。拦截器还指定了在Action类执行前后出现的动作顺序。如前所述,拦截器经配置后,可以把常见功能作用到请求上。该框架的大多数核心功能作为拦截器来实现。如果有些动作响应了Ajax、SOAP或者JSF请求,生命周期就能得到简化,请求也只需通过拦截器传送,不需要任何执行。


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(请参考:docs\actionmapper.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对象。

Struts 1与Struts 2的比较
Struts 1和Struts 2有三个共同的基本概念: 请求处理程序、响应处理程序和标签库。不过在Struts 2中,这些部分经过了重新设计,并得到了改进,以便开发。


开发人员会注意到Struts 2框架中出现的许多改动。譬如说,过滤器取代了服务器小程序,相应变化在部署描述文件里会有所体现。同样,配置文件经过了全面改动。还会注意到其他一些关键特性,譬如Action类方面的变化、支持注释、验证方面的变化。表1详细解释了这些变化。struts2.0新特性以及和struts1.2的区别


Struts 2.0的新特性
Struts 2.0框架中出现的许多特性旨在让Struts更容易使用:
● 改进的设计: 与Struts 1相比,Struts 2的所有类都基于接口,核心接口独立于HTTP。这些API并不依赖服务器小程序API。


简化的Action: Struts 2 Action类独立于框架,是简化的普通Java对象(POJO)。拥有execute()方法的任何Java类都可以用做Action类。


POJO表单: Struts 2不支持ActionForms特性。ActionForms中定义的属性可以直接放在Action类上。不需要使用所有的String属性。


● 智能默认值: Struts 2配置文件中的大多数配置元素都会有默认值,所以不需要设定值,除非需要不同的值。这有助于减少在XML文件中需要进行的配置。Struts 2支持注释,这带来了更大的方便。


改进的结果: 在Struts 2中,
>forward<标签被<result>标签取代。不像 ActionForwards,Struts 2结果可以帮助准备响应,并提供构建多种输出类型的灵活性。


● 改进的标签: Struts 2标签不单单发送输出数据,还能提供样式表驱动标记,这样就可以用较少的代码构建一致性页面。Struts 2标签现在可与FreeMarker、Velocity及类似模板引擎配合使用。


引入拦截器: Struts 2为拦截器(interceptor)提供了全面支持。拦截器可在Action类执行前后加以执行。拦截器经配置后,可以把工作流程或者验证等常见功能作用到请求上。所有请求通过一组拦截器传送,之后再发送到Action类。Action类被执行后,请求按照相反顺序再次通过拦截器传送。


● 支持Ajax: 为了创建使用Ajax的动态Web应用,Struts 2提供了Ajax主题,从而大大改进了交互应用。面向Ajax的Struts 2标签基于Dojo窗口组件。还有用于其他框架的插件。


● 快速启动: 部署配置文件可以重新装入; 因而,可以动态地进行许多变化,用不着重新启动Web容器。


● 状态复选框: Struts 2框架可自动跟踪复选框,如果缺少了某复选框,就会采用默认值false。因而,不像在Struts 1中,复选框不需要对false值进行特殊处理。


易于测试: Struts 2 Actions独立于HTTP,因而与框架中立。无须使用模拟对象(mock object),就很容易测试。


使用注释: 使用Struts 2开发的应用可以使用Java 5注释,作为XML和Java属性配置之外的一个替代办法。注释尽量减少了对XML的需要。Action、拦截器、验证及类型转换方面都有注释。


● 易于插入: 只要把插件JAR文件放到\WEB-INF\lib目录中,即可轻松安装Struts 2插件,不需要手动配置。


● 便于与Spring集成: Struts 2 Action能够感知Spring(Spring-aware)。只要为某个应用添加Spring beans,就可以添加对Spring的支持。


● 易于定制的控制器: Struts 1允许请求处理程序可按照模块来定制,在Struts 2中,需要的话,可以按照动作来定制请求处理。

【总结:】
一个请求在Struts2框架中的处理大概分为以下几个步骤

1) 客户端初始化一个指向Servlet容器(例如Tomcat)的请求


2) 这个请求经过一系列的过滤器(Filter)(这些过滤器中有一个叫做ActionContextCleanUp的可选过滤器,这个过滤器对于Struts2和其他框架的集成很有帮助,例如:SiteMesh Plugin)


3) 接着FilterDispatcher被调用,FilterDispatcher询问ActionMapper来决定这个请求是否需要调用某个Action。


4) 如果ActionMapper决定需要调用某个Action,FilterDispatcher把请求的处理交给ActionProxy。


5) ActionProxy通过Configuration Manager询问框架的配置文件,找到需要调用的Action类。


6) ActionProxy创建一个ActionInvocation的实例。


7) ActionInvocation 实例使用命名模式来调用,回调Action的execute方法,该execute方法先获取用户请求参数,然后它会调用业务逻辑组件来处理用户的请求。在调用Action的过程前后,涉及到相关拦截器(Intercepter)的调用。


8) 一旦Action执行完毕,ActionInvocation负责根据struts.xml中的配置找到对应的返回结果。返回结果通常是(但不总是,也可能是另外的一个 Action链)一个需要被表示的JSP或者FreeMarker的模版。在表示的过程中可以使用Struts2 框架中继承的标签。在这个过程中需要涉及到ActionMapper。


在上述过程中所有的对象(Action,Results,Interceptors,等)都是通过ObjectFactory来创建的。


2. Struts 1和Struts 2对比

2.1. 在Action实现类方面的对比:
Struts 1要求Action类继承一个抽象基类;Struts 1的一个具体问题是使用抽象类编程而不是接口。
Struts 2 Action类可以实现一个Action接口,也可以实现其他接口,使可选和定制的服务成为可能。Struts 2提供一个ActionSupport基类去实现常用的接口。即使Action接口不是必须实现的,只有一个包含execute方法的POJO类都可以用作Struts 2的Action。


2.2. 线程模式方面的对比:
Struts 1 Action是单例模式并且必须是线程安全的,因为仅有Action的一个实例来处理所有的请求。单例策略限制了Struts 1 Action能做的事,并且要在开发时特别小心。Action资源必须是线程安全的或同步的;
Struts 2 Action对象为每一个请求产生一个实例,因此没有线程安全问题。


2.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,从而给开发者更多灵活的选择。


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


2.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,从而降低了代码污染。


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


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

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


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


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

 

你可能感兴趣的:(spring,应用服务器,Web,框架,struts)