Java之旅Struts系列（4）——Struts2（精华）

　　很多人都会文Struts2和Struts1的区别，讲完这篇文章相比大家对于Struts1和Struts2都能有一个理解。

　　Struts1蓬勃发展的同时，也存在了一些问题，那就是侵入性的设计使得代码的复用性降低，为了能够应对这种情形，WebWork的出现将其在一定程度上得到了解决；新事物不断地崛起，为了给“老”的Struts1注入新的血液，Struts也在不断地发展。

　　Struts分化出来两个框架，第一个是传统的Struts1与WebWork结合后的Struts2，另一个框架是Shale,这里不做详细的介绍，不是本篇的重点。

　　Struts2虽然是在Struts1的基础上发展起来的，但是却是以WebWork为核心的，也就是说在原有的基础上注入的是新鲜血液WebWork的思想，Struts2与WebWork很像的，之前转载过一篇文章大家也可以看看：

http://blog.csdn.net/u010955843/article/details/48317587，Struts2是以WebWork为核心而非Struts1，并且看过WebWork再看Struts2会很容易的，Struts2不是Struts1的升级。

　1.      Struts2理论讲解

　　流程解析

　　与WebWork相似，Struts2同样使用了拦截器处理用户的请求，从而将用户的业务逻辑与Servlet API进行了分离。

　　处理流程与WebWork相似，同样也会创建一个代理控制器，从而进行用户请求的相关处理，处理用户请求的时候回调业务逻辑控制器的execute方法，此时的核心控制器不同于WebWork，此时为FilterDispatcher,WebWork的为ServletDispatcher。

　　处理流程是：浏览器发送客户的请求，比如/role_list.action等等，核心控制器（FilterDispatcher）进行相关的拦截并根据相关的请求调用合适的action，回调Action中的execute方法，该方法对用户的请求进行处理并且将相关的处理结果进行返回。

　　Struts2的核心配置文件

　　Struts2的核心配置文件是struts.xml，具体的配置如下图：

　　这个示例中配置文件定义了两个action，不仅仅定义了action的实例并且将相应的处理结果也进行了定义也就是返回的视图名称与相应的视图资源进行了配置。

　　表现在Result中指定了execute返回值与视图资源之间的映射关系。比如当执行退出action的时候，页面跳转的是欢迎界面action。

　　其中name指定的是execute中返回的字符串的名字，而type指定转向的资源类型，可以是jsp页面，当然也可以是另一个action。

　　全局属性文件struts.properties

　　Struts.deMode=false:开发模式下设为true，这样可以打印出更详细的错误信息;

　　Struts.configuration.xml.reload=true,在开发阶段设置为true，这样是支持热部署的。

　　关于其他还有的更加详细的其他配置：

　　http://www.cnblogs.com/yangy608/archive/2010/11/08/1871962.html

　　标签库

　　与WebWork以及Struts1存在相似之处，Struts2也存在丰富的标签库，Struts标签的使用可以最大限度的减少页面代码的书写。

　　这样的对比是不是很明显呢？前面是使用标签库的，后者是我们普通的html拼写的表单。

并且Struts是支持我们前面说的强大表达式语言OGNL的。

　　第一Action实例没有继承或者实现任何的接口和类，是一个完全的pojo对象，使得代码的复用性很好，第二就是execute方法没有依赖于任何的Struts API以及Servlet API，并且返回结果是一个字符串，可以映射到任何的视图，同样可以是另一个action实例。

　　关于实战，我们下篇再讲，讲到这里大家想必对于Struts1和Struts2以及WebWork有了一定的了解了，下面我们来看看他们之前的区别和联系。

　2.      Struts1和Struts2的区别

　　（1）       代码复用性方面：Struts1是继承Action基类的，也就是我们常说的使用抽象类编程而不是接口编程，不同于可以实现Action的接口当然也可以不实现此接口，同样也是可以实现其他的接口的。再者Struts1严重依赖于Servlet API，因为execute方法中就含有httpServletRequest等等，这样使得其依赖于web容器，而Struts2是不依赖于Servlet API的，这样使得其可以脱离web容器进行运行。

　　（2）       表单参数的封装：我们知道Struts1获取表单的参数是根据ActionForm类来获取的表单的参数，并且这个ActionForm实例必须继承ActionForm，普通的javaBean对象是无法充当ActionForm的。也就是说我们如果有大量的表单页面就需要建立大量的ActionForm类并且需要在配置文件中进行配置，显然这也是不现实的；但是在Struts2里面Action封装了这些请求参数，此外如果我们的表单参数特别多的话我们可以使用ModelDriven模式，与Struts1的ActionForm相似，将表单的参数进行封装，让action实现ModelDriven接口即可获取封装好的model对象。

　　（3）       数据显示：Struts1将处理结果返回绑定到jsp页面，而Struts2使用的值栈技术，可以通过标签库进行相应值的访问。

　3.      小结

　　讲解完理论，我们来讲解Struts2的应用，不要走开，精彩继续~