Struts 2 学习总结
1. Web技术的发展
静态页面->CGI开创动态执行Web应用时代->Servlet技术->Model 1 JSP(JSP兼具View和Controller角色)->Model 2 JSP
Model1 JSP页面兼具View和Controller两种角色,控制逻辑和表现逻辑混合在一起,导致代码的重用性非常低,增加了应用扩展性和维护性的难度。
Model2中,在Servlet中只包含控制逻辑和简单的前段处理,然后调用后端的JavaBean来完成实际的逻辑处理,最后转发到相应的JSP页面处理显示逻辑。
在Model2中,JSP不再承担控制器的角色,仅仅是表现层角色,将数据呈现给用户,JSP页面的请求与Servlet(控制器)交互,而Servlet负责与后台的JavaBean通信。在Model2中,View = JSP Controller = Servlet Model = JavaBean。
2. MVC思想及其优势
MVC思想将一个应用分成三个基本部分:Model(模型),View(试图)和Controller(控制器)。这三个部分以最少的耦合协同工作,从而提高应用的可扩展性和可维护性。
Spring MVC框架简单了解
该框架为模型、视图、控制器之间提供了一个非常清晰的划分,各部分耦合极低。Spring的MVC是非常灵活的,它完全基于接口编程,真正实现了视图无关。视图不再强制要求使用JSP,可以使用Velocity、XSLT或其他视图技术。甚至可以使用自定义的视图机制——只需要简单地实现View接口,并且把对应视图技术集成进来。Spring的Controllers由IoC容器管理。因此,单元测试更加方便。
SpringMVC框架以DispatcherServlet为核心控制器,该控制器负责拦截用户的所有请求,将请求分发到对应的业务控制器。SpringMVC框架有一个极好的优势,就是它的视图解析策略:它的控制器返回一个ModelAndView对象,该对象包含视图名字和Model,Model提供了Bean的名字及其对象的对应关系。视图名解析的配置非常灵活,抽象的Model完全独立于表现层技术,不会与任何表现层耦合:JSP、Velocity或者其他的技术——都可以和Spring整合。
3. Struts 2的起源和背景
Struts 1 简介
Struts 1框架以ActionServlet作为核心控制器,整个应用由客户端请求驱动。当客户端向Web应用发送请求时,请求将被Struts 1的核心控制器ActionServlet拦截,ActionServlet根据请求决定是否需要调用业务逻辑控制器处理用户请求(实际上,业务逻辑控制器还是控制器,它只是负责调用模型来处理用户请求),当用户请求处理完成后,其处理结果通过JSP呈现给用户。
对于整个Struts 1框架而言,控制器就是它的核心,Struts 1的控制器由两个部分组成:核心控制器和业务逻辑控制器。其中核心控制器就是ActionServlet,由Struts 1框架提供;业务逻辑控制就是用户自定义的Action,由应用开发者提供。
对于大部分用户请求而言,都需要得到服务器的处理。当用户发送一个需要得到服务器处理的请求时,该请求被ActionServlet拦截到,ActionServlet将该请求转发给对应的业务逻辑控制器,业务逻辑控制器调用模型来处理用户请求;如果用户请求只是希望得到某个URL资源,则由ActionServlet将被请求的资源转发给用户。
Struts 1程序流程具体分析MVC中的三个角色。
1) Model部分
Struts 1的Model部分主要由底层的业务逻辑组件充当,这些业务逻辑组件封装了底层数据库访问、业务逻辑方法实现。实际上,对于一个成熟的企业应用而言,Model部分也不是一个简单的JavaBean所能完成的,它可能是一个或多个EJB组件,可能是一个WebService服务。总之,Model部分封装了整个应用的所有业务逻辑,但整个部分并不是由Struts 1提供的,Struts 1也没有为实现Model组件提供任何支持。
2) View部分
Struts 1的View部分采用JSP实现。Struts 1提供了丰富的标签库,通过这些标签库可以最大限度地减少脚本的使用。这些自定义的标签库可以输出控制器的处理结果。
虽然Struts 1提供了与Ties框架的整合,但Struts 1所支持的表现层技术非常单一:既不支持FreeMarker、Velocity等模板技术,也不支持JasperReports等报表技术。
3) Controller部分
Struts 1的Controller由两个部分组成。
系统核心控制器:由Struts 1框架提供,就是系统中的ActionServlet。
业务逻辑控制器:由Struts 1框架提供,就是用户自己实现的Action实例。
Struts 1的核心控制器对应图1.7中的核心控制器(ActionServlet)。该控制器由Struts 1框架提供,继承HttpServlet类,因此可以配置成一个标准的Servlet,该控制器负责拦截所有HTTP请求,然后根据用户请求决定是否需要调用业务逻辑控制器,如果需要调用业务逻辑控制器,则将请求转发给Action处理,否则直接转向请求的JSP页面。
业务逻辑控制器负责处理用户请求,但业务逻辑控制器本身并不具有处理能力,而是调用Model来完成处理。
Struts 1提供了系统所需要的核心控制器,也为实现业务逻辑控制器提供了许多支持。因此,控制器部分就是Struts 1框架的核心。
Struts 1的缺点
1) 支持的表现层技术单一
2) 与Servlet API严重耦合,难于测试
3) 代码严重依赖于Struts 1 API,属于侵入式设计
WebWork简介
相对于Struts 1存在的那些先天性不足而言,WebWork则更加优秀,它采用了一种更加松耦合的设计,让系统的Action不再与Servlet API耦合。使单元测试更加方便,允许系统从B/S结构向C/S结构转换。WebWork支持更多的表现层技术。WebWork有自己的控制反转(Inversion of Control)容器,通过控制反转,可以让测试变得更简单,测试中设置实现服务接口的Mock对象完成测试,而不需要设置服务注册。
从处理流程上来看,WebWork与Struts 1非常类似,它们的核心都由控制器组成,其中控制器都由两个部分组成:
1) 核心控制器ServletDispatcher,该控制器框架提供。
2) 业务逻辑控制器Action,该控制器由程序员提供。
WebWork的Action可以与Servlet API分离,得益于它灵巧的设计,它使用一个拦截器链,负责将用户请求数据转发到Action,并负责将Action的处理结果转换成对用户的响应。
当用户向Web应用发送请求时,该请求经过ActionContextCleanUp、SiteMesh等过滤器过滤,由WebWork的核心控制器拦截,如果用户请求需要WebWork的业务逻辑控制器处理,该控制器则调用Action映射器,该映射器将用户请求转发到对应的业务逻辑控制器。值得注意的是,此时的业务逻辑控制器并不是开发者实现的控制器,而是WebWork创建的控制器代理。
创建控制器代理时,WebWork需要得到开发者定义的xwork.xml配置文件,控制器代理以用户实现的控制器作为目标,以拦截器链中的拦截器作为处理(Advice)。
开发者自己实现的业务逻辑控制器只是WebWork业务控制器的目标——这就是为什么开发者自己实现的Action可以与Servlet API分离的原因。当开发者自己的Action处理完HTTP请求后,该结果只是一个普通字符串,该字符串将对应到指定的视图资源。
指定的试图资源经过拦截器链的处理后,生成对客户端的响应输出。
相对Struts1,WebWork的优点有:
1)Action无需与Servlet API耦合,更容易测试
2)Action无需与WebWork耦合,代码重用率高
3)支持更多的表现层技术,有更好的适应性
4.Struts 2体系介绍
Struts 2与WebWork相差不大,Struts 2同样使用拦截器作为处理(Advice),以用户的业务逻辑控制器为目标,创建一个控制器代理。控制器代理负责处理用户请求,处理用户请求时回调业务控制器的execute方法,该方法的返回值将决定了Struts 2将怎样的视图资源呈现给用户。
Struts 2框架的大致处理流程
浏览器发送请求,例如请求/mypage.action、/reports/myreport.pdf等。
核心控制器FilterDispatcher根据请求决定调用合适的Action。
WebWork的拦截器链自动对请求应用通用功能,例如workflow、validation或文件上传等功能。
回调Action的execute方法,该execute方法先获取用户请求参数,然后执行某种数据库操作,既可以是将数据保存到数据库,也可以从数据库中检索信息。实际上,因为Action只是一个控制器,它会调用业务逻辑组件来处理用户的请求。
Action的execute方法处理结果信息将被输出到浏览器中,可以是HTML页面、图像,也可以是PDF文档或者其他文档。此时支持的视图技术非常多,既支持JSP,也支持Velocity、FreeMarker等模板技术。
Struts 2的配置文件
当Struts 2创建系统的Action代理时,需要使用Struts 2的配置文件。
Struts 2的配置文件有两份:
配置Action的struts.xml文件。
配置Struts 2全局属性的struts.properties文件。
struts.xml文件内定义了Struts 2的系列Action,定义Action时,指定该Action的实现类,并定义该Action处理结果与视图资源之间的映射关系
Struts 2还有一个配置Struts 2全局属性的Properties文件:struts.properties.struts.properties文件的形式是系列的key、value对,它指定了Struts 2应用的全局属性。
Strut 2的标签库
Struts 2的标签库也是Struts 2的重要组成部分,Struts 2的标签库提供了非常丰富的功能,这些标签库不仅提供了表现层数据处理,而且提供了基本的流程控制功能,还提供了国际化、Ajax支持等功能。
Struts 2的控制器组件
Struts 2的控制器组件是Struts 2框架的核心,事实上,所有MVC框架都是以控制器组件为核心的。正如前面提到的,Struts 2的控制器由两个部分组成:
FilterDispatcher和业务控制器Action。
实际上,Struts 2应用中起作用的业务控制器不是用户定义的Action,而是系统生成的Action代理,但该Action代理以用户定义的Action为目标
Struts 2 的业务控制器Action类的优点:
Action类完全是一个POJO,因此具有很好的代码复用性。
Action类无需与Servlet API耦合,因此进行单元测试非常简单。
Action类的execute方法仅返回一个字符串作为处理结果,该处理结果可映射到任何的视图,甚至是另一个Action。
Struts 2与Struts 1的对比
1)在Action实现类方面的对比:Struts 1要求Action类继承一个抽象基类;Struts 1的一个具体问题是使用抽象类编程而不是接口。Struts 2 Action类可以实现一个Action接口,也可以实现其他接口,使可选和定制的服务成为可能。
2)线程模式方面的对比:Struts 1 Action是单例模式并且必须是线程安全的,因为仅有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的难度。
4)可测性方面的对比:测试Struts 1 Action的一个主要问题是execute方法依赖于Servlet API,这使得Action的测试要依赖于Web容器。Struts 2 Action可以通过初始化、设置属性、调用方法来测试。
5)封装请求参数的对比:Struts 1使用ActionForm对象封装用户的请求参数,所有的ActionForm必须继承一个基类:ActionForm。Struts 2直接使用Action属性来封装用户请求属性,避免了开发者需要大量开发ActionForm类的烦琐
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一起使用。
WebWork和Struts 2对比
AroundInterceptor:Struts 2不再支持WebWork中的AroundInterceptor。
富文本编辑器标签:Struts 2不再支持WebWork的富文本编辑器
IoC容器支持:Struts 2不再支持内建的IoC容器,而改为全面支持Spring的IoC容器,以Spring的IoC容器作为默认的Object工厂。