读《struts2权威指南》

1.
---------------------------------------
struts2的起源和背景：
---------------------------------------
struts2以WebWork优秀的设计思想为核心，吸收了struts1的部分优点，建立了一个兼容webWork和struts1的MVC框架，struts2的目标希望让原来使用strut1、webwork的开发人员，都可以平稳的过渡到使用struts2框架

2.
---------------------------------------
struts1的控制器有两个部分组成：
---------------------------------------
核心控制器和业务逻辑控制器，其中核心控制器就是ActionServlet，由Struts1框架提供；业务逻辑控制器就是用户自定义的Action类，此类一定会集成自Action或者DeispatcherAction，由应用开发者提供

3.
---------------------------------------
struts1的MVC模式中的三种角色：
---------------------------------------
（1）Model部分主要由底层的业务逻辑组建充当，这些业务逻辑组建封装了底层数据库访问、业务逻辑方法实现
（2）View部分采用了Jsp实现，struts1提供了丰富的标签库，通过这些标签库可以最大限度的减少脚本的使用，这些自定义的标签库可以输出控制器的处理结果
（3）Controller部分由两个部分组成：
A。系统核心控制器：由struts1框架提供，系统中的ActioinServlet，当然在/WEB-INF/web.xml文件中会被注册
B。业务逻辑控制器：由struts1框架提供，用户自定义实现的Action实例

4.
---------------------------------------
struts的缺陷：
---------------------------------------
（1）支持的表现层技术单一，只是单纯的支持Jsp作为表现层技术，不提供其他表现层技术：Velocity， FreeMarker等技术的整合
（2）与ServletAPI严重耦合，难于测试；例如HttpServletRequest和HttpServletResponse两个参数是ServletAPI，严重依赖于Web服务器，一旦脱离服务器，Action的测试非常困难。
（3）代码严重以来与Struts1 API，属于侵入式设计，一旦系统需要重构时，Action类完全没有利用价值，成为一对废品。这种侵入式的设计倒是了较低的代码复用性

5.
---------------------------------------
WebWork简介：
---------------------------------------
来自于优秀的开源项目：opensymphony，创始人：Rickard Oberg（JBoss和XDoclet的作者），相对于struts1的先天性不足，它采用了一种更加松耦合的设计，让系统的Action不再与Servlet API耦合，使单元测试更加方便，允许系统从b/s结构向c/s结构转换.
WebWork有自己的控制反转机制,这样测试就会变得很是简单;同时使用OGNL这种强大的表达式语言,可以访问值栈,OGNL对集合和索引属性的支持非常强大;建立在XWork之上,使用ServletDispatch作为框架的核心控制器,处理HTTP请求和响应,使用Action作为业务逻辑控制器,由程序员提供

6.
---------------------------------------
WebWork运行流程:
---------------------------------------
当用户向Web应用发送请求时,该请求经过ActionContextCleanUp,SiteMesh等过滤器过滤,由WebWork和核心控制器拦截,如果用户请求需要WebWork的业务逻辑控制器处理,该控制器调用Action映射器,该映射器将用户请求需要WebWork的业务逻辑控制器处理,该控制器则调用Action映射器,该映射器将用户请求转发到对应的业务逻辑控制器.此时的业务逻辑控制器并不是开发者实现的控制器,而是WebWork创建的控制器代理;创建控制器代理时,WebWork需要得到开发者定义的xwork.xml配置文件,控制器代理以用户实现的控制器作为目标,以拦截器链中的拦截器作为处理(Advice).此种方式就是典型的AOP编程方式；开发者自己实现的业务逻辑控制器只是WebWork业务逻辑控制器的目标，这就是为什么开发者自己实现的Action可以与Servlet API分离的原因，当开发者自己的Action处理完HTTP请求后，该结果只是一个普通的字符串，该字符串将对应到指定的视图资源，指定的视图资源经过拦截器链的处理后，生成对客户端的响应输出。

7.
---------------------------------------
struts1和WebWork的区别：
---------------------------------------
（1）Action无需与Servlet API耦合，更容易测试
（2）Action无需与WebWork耦合，代码重用率高；实现一个接口和继承一个类是完全不同的概念，实现一个接口对类的污染要小的多，该类也可以实现其他任意接口，还可以继承一个父类；但时继承一个父类，则一位着该类不能在继承其他父类；况且在Struts1中的execute方法中需要四个参数，该代码除了在struts1框架下还有所用处外，没有任何的复用价值。而WebWork的execute方法则完全不同，该方法中没有出现任何的Servlet API，也没有出现任何的WebWork API，在任何环境下都由复用的价值
（3）支持更过的表现层技术，有更好的适应性

8.
---------------------------------------
Struts2起源：
---------------------------------------
五年的发展，struts1已经是一个高度成熟的框架，稳定性，可靠性都得到了广泛的证明，struts1和WebWork结合后诞生的Struts2框架。struts2虽然在struts1的基础上发展起来的，但实质是以WebWork为核心，struts2为传统struts1注入了WebWork的设计理念，统一了struts1和WebWork两个框架，从而允许struts1和WebWork开发者同时使用Struts2框架

9.
---------------------------------------
struts2体系介绍：
---------------------------------------
与struts1体系的差别非常大，因为struts2使用了WebWork的设计核心，而不是使用Struts1的设计核心，struts2大量使用拦截器来处
理用户请求，从而允许用户的业务逻辑控制器与Servlet API分离。

10.
---------------------------------------
Struts2框架的大致处理流程：
---------------------------------------
（1）浏览器发送请求，例如：请求myPage.action
（2）核心控制器FilterDispatcher根据请求决定调用合适的Action
（3）WebWork的拦截器链自动对请求应用通用功能，例如：workFlow，validatation或文件上传等功能
（4）回调Action的execute方法，该execute方法先获取用户请求参数，然后执行某种数据库操作，既可以是将数据保存到数据库，也可以从数据库中检索信息，实际上，因为Action只是一个控制器，它会调用业务逻辑组件来处理用户的请求。
（5）Action的execute方法处理结果信息将被输出到浏览器中，可以时HTTP页面，图像，也可以是PDF文档或者其他文档，或者其他视图技术

11.
---------------------------------------
Struts2的配置文件：当struts2创建系统的Action代理时，需要使用Struts2的配置文件
---------------------------------------
分为两个部分：
（1）配置Action的struts.xml文件：此文件中定义了struts2的系列Action，定义Action时，指定该Action的实现类，并定义该Action处理结果与视图资源之间的映射关系；所有的Action都必须配置在package节点下

（2）配置sturts2全局属性的struts.properties文件

12.
---------------------------------------
struts2的标签库
---------------------------------------
struts的标签库提供了丰富的功能，这些标签库不仅提供了表现层数据处理，而且提供了基本的流程控制功能，还提供了国际化，Ajax支持等功能，这样开发者就可以最大限度的减少页面代码的书写。struts2标签库的功能非常复杂，几乎可以完全替代JSTL的标签库，而且struts2标签库支持表达式语言，这种表达式语言支持一个强大和灵活的表达式语言：OGNL；

13.
---------------------------------------
struts的控制器组件：
---------------------------------------
此组件是struts2框架的核心，所有的MVC框架都是以控制器组件为核心的。正真起作用的是业务逻辑控制器并不是用户自定义的Action，而是系统生成的Action代理，但是该代理以用户定义的Action为目标。用户自定义的Action类完全是一个POJO（普通、传统的Java对象）因此具有很好的复用性。

14.
---------------------------------------
Struts2中的Action类所具有的优势：
---------------------------------------
（1）Action类完全是一个POJO，因此具有很好的代码复用性
（2）Action类无需与 Servlet API耦合，因此进行单元测试非常简单
（3）Action类的execute方法仅返回一个字符串作为处理结果，该处理结果映射到任何的视图，甚至是另外一个Action

15.
---------------------------------------
struts2和struts1的对比
---------------------------------------
（1）在Action实现类方面的对比：struts1要求Action类继承一个抽象基类,struts1的一个具体问题是使用抽象类编程而不是接口，struts2 Action类可以实现一个Action接口，也可以实现其他接口，使可选和定制的服务成为可能，struts2 提供一个ActionSuport基类去实现常用的接口。
（2）线程模式方面的对比：struts1 Action是单例模式并且必须是线程安全的，因为仅有Action的一个实例来处理所有的请求，单例策略限制了Struts1 Action能做的事，并且在开发时特别小心。Action资源必须是线程安全的或同步的；Struts2Action对象为每一个请求产生一个实例，因此没有线程安全问题。
（3）Servlet以来方面的对比：Struts1 Action依赖于Servlet API，因为struts1 Action的execute方法中有HttpServletRequest和HttpServletResponse接口，Struts2中不再依赖于Servlet API，从而允许Action 脱离Web容器运行，从而降低了测试Action的难度，大部分时候Action都无需直接访问HttpServletRequest和HttpServletResponse，从而给开发者更多的灵活性
（4）可侧性方面对比：测试Struts1 Action的一个主要问题是execte方法依赖于Servlet API，这使得Action的测试要依赖于Web容器，为了脱离Web容器测试Struts1的Action，必须借助于第三方扩展：Struts TestCase。而Struts2 Action可以通过初始化、设置属性、调用方法来测试
（5）封装请求参数的对比：struts1 使用ActionForm对像封装用户的请求参数，所有的ActionForm必须继承一个基类：ActionForm，实体类不能用作ActionForm进行封装数据；Struts2中可以直接使用Action属性封装用户请求属性
（6）表达式语言方面的对比：struts1整合了JSTL，因此可以使用JSTL表达式语言，struts2中整合一种更强大和灵活的表达式语言：OGNL
（7）绑定值到试图的对比：struts1使用标准Jsp机制把对象绑定到试图页面；struts2使用ValueStack技术，使标签库能够访问值，而不需要把对象和视图页面绑定在一起。
（8）类型转换的对比：struts1 ActionForm属性通常都是String 类型的，struts1使用Commons-Beanutils进行类型转化，每一个类一个转换器，转换器是不可配置的，struts2使用OGNL进行类型转换，支持基本数据类型和常用常用对象之间的转换。
（9）数据校验对比：struts1支持在ActionFrom重写validate方法手动校验，或者通过整合Commons alidator框架来完成数据校验。struts2支持通过validate方法进行校验，也支持整合XWork校验框架进行校验
（10）Action执行控制的对比：struts1支持每一个模块对应一个请求处理，但是模块中的所有Action必须共享相同的生命周期，struts2通过拦截器堆栈为每一个Action创建不同的生命周期

16.
---------------------------------------
struts2和WebWork的对比
---------------------------------------
从某种意义上说struts2是WebWork的升级，而不是struts1的升级，甚至在Apache的struts2的官方文档都提到：WebWork到struts2是一次平缓的过度，实际上struts2是WebWork2.3而已，从WebWork2.2迁移到Struts2.0不会比从WebWork2.1到2.2更麻烦

17.
---------------------------------------
struts2基本流程
---------------------------------------
组成：核心控制器FilterDispatcher（struts2框架提供），业务控制器，用户实现的业务逻辑组件（这两者由用户提供）

1.核心控制器：它作为一个Filter运行在Web应用中，负责拦截所有的用户请求，当用户请求到达时，该Filter会过滤用户请求，struts2用于处理用户请求的Action实例，并不是用户实现的业务逻辑控制器，而是Action代理，因为用户实现的业务逻辑控制器并没有Servlet API耦合，显然无法处理用户请求。而Struts2框架提供了系列拦截器，该系列拦截器负责将HttpServletRequest请求中的请求参数解析出来，传入到Action中，并回调Action的execute方法来处理用户请求。

2.业务控制器：业务控制器组件时用户实现Action类的实例，正是struts2所要处理的用户请求的实例，程序员开发出系统所需的业务控制器后，还需配置Struts2的Action：Action所处理的URL；Action组件所对应的实现类；Action里包含的逻辑视图和物理资源之间的对应关系。每个Action都要处理一个用户请求，而用户请求总是包含了指定的URL，当FilterDispatcher拦截到用户请求后，根据请求的URL和Action处理URL之间的对应关系来处理转发。

18.
---------------------------------------
Action成为控制器的原因：
---------------------------------------
通常MVC框架里的业务逻辑控制器会调用模型组件的方法来处理用户请求，业务逻辑控制器不会对用户请求进行任何实际的处理，用户请求最终有模型组件负责处理。业务控制器只是中间负责调度的调度器，这也是Action为控制器的原因

19.
---------------------------------------
Struts2的运行流程：
---------------------------------------
struts2.0技术等同于WebWork2.3框架，除了包和属性被改名外，从WebWork2.2迁移到struts2下不会比从WebWork2.1迁移到WebWork2.2更复杂

20.
---------------------------------------
Struts2的基本配置：
---------------------------------------
1.web.xml:任何MVC框架都需要与Web应用整合，这就不得不借助于Web.xml文件，只有配置在web.xml文件中的Servlet才会被应用加载。通常的所有的MVC框架都需要Web应用加载一个核心控制器，对于struts2框架而言，需要加载FilterDispatcher，主要Web应用负责加载FilterDispatcher，FilterDispatcher将会加载应用的Struts2框架。因为Struts2将核心控制器设置为Filter，而不是一个普通Servlet。

2.struts.xml:struts框架的核心配置文件就是struts.xml配置文件，主要负责管理struts2框架的业务控制器Action，以及该Action包含的result定义。为了避免struts的xml文件的庞大、臃肿，同时为了提高此文件的可读性，我们可以将struts.xml文件分解成多个配置文件，之后在文件中包含其他配置文件，当然所有的配置文件必须时完整的。

3.struts.properties配置文件：
定义struts2框架的大量属性，开发者通过改变这些属性来满足应用的需求，此文件中包含了一系列的key-value对象，只要将该文件放置在CLASSPATH路径下，struts2框架就可以加载此文件。