Java之旅Struts系列（3）——Struts2（前奏篇）-CSDN博客

本文链接：https://blog.csdn.net/u010955843/article/details/48684391

　　上篇博客我们已经讲到了Struts1的Action类这种侵入式设计使得代码的复用率极低，那么是不是有别的解决方案呢，答案当然是有的。

　　可能有的同学已经想到了是Struts2，也就是我们本篇要讲的，但是在讲解这个之前，我们先来了解一个别的mvc模式的框架：WebWork，了解了这个之后我们再来了解Struts2,效果肯定会更加的明显和高效。

　　WebWork来自于另一个优秀的开源组织，相对于Struts1中的严重耦合或者说依赖，WebWork显然要更加的优秀，去除了Action与Servlet API 的耦合，这样也便于我们进行测试。

　　对比与Struts1，WebWork在表现层支持方法支持的技术比较丰富，此外面对于Struts1依赖于web容器进行初始化的现象，WebWork是可以脱离web应用进行工作的，它拥有自己的控制反转（Inversion of Control）容器，还有就是WebWork2使用OGNL这个强大的语言表达式，可以访问值栈，OGNL强有力支持集合和索引。

　　与Struts1处理流程是相似的，同样存在核心控制器和业务逻辑控制器，但是这里的核心控制器不再是ActionServlet而是ServletDispatcher，这个由框架进行提供，而业务逻辑Action由程序员进行提供。

　　下面进行了一下关于WebWork的讲解。

　1. WebWork流程详解

　　我们先来看一个流程图：

　　具体是怎么工作的呢？流程详解：

　　当用户向web应用发送一个http请求的时候，该请求经过ActionContextCleanUp、SiteMesh等过滤器，再由WebWork的核心控制器ServletDispatcher进行拦截，如果用户的请求需要WebWork的业务逻辑控制器处理，该控制器则调用Action映射器，该映射器将用户的请求转发到对应的业务逻辑控制器，但是我们可以根据图示发现，此时的业务逻辑控制器并不是我们开发实现的控制器，而是WebWork创建的代理控制器。

　　创建的这些需要在WebWork的核心配置文件xwork.xml中进行相关的定义，使得控制器以用户实现的控制器作为目标，以拦截器链中拦截器作为处理。此时代理控制器由系统代为实现，无需我们的参加。

　　因为此时开发者实现的是WebWork控制器的目标，这样就使得WebWork的action可以与Servlet API进行分离，当自己的Action处理完用户的请求后，返回一个普通的字符串名称，从而在配置文件中将此名称指向相应的视图资源。

　　与Struts1相比，WebWork存在很多的优势之处，不用与ServletAPI耦合

　　此时我们看到Action实例只是实现了一个Action接口，并且实现其中的方法。

　　此时我们发现在execute方法中没有了Struts1中的继承来的四个参数，这样就去除了与Struts1API以及Servlet API的依赖，Action中的参数与httpServletRequest无关，我们可以看到该action封装了表单上的两个参数，这两个参数初始化由Action拦截器负责，以用户请求参数为其进行赋值。

　　WebWork很好滴解除了依赖，我们可以看到即使我们访问了http session ，但是还是没有出现相应的关于session的api,而是通过map的形式通过值栈进行读取。

　　总之，Action是不必要与WebWork进行耦合的，这样使得代码的重用率得到了提高。其实在WebWork 中的action更像是一个pojo对象，虽然实现了Action接口，但是也仅仅是包含了一个execute方法，可以对比与Struts1中Action，我们可以看到继承来的Action具有严重的依赖性不仅仅依赖于Struts1 API，而且依赖于ServletAPI,此外继承和实现接口相比，继承一个父类之后意味着不能再继承，但是实现接口后还是可以再继承呢，便于扩展。

　2. 标签库—OGNL

　　与Struts1存在相似之处，WebWork也提供了丰富的标签库，在讲解这个之前我们最需要了解的是一个强大的语言支持OGNL.

　　什么是OGNL?

　　OGNL是Object-Graph Navigation Language的缩写，它是一种功能强大的表达式语言，通过它简单一致的表达式语法，可以存取对象的任意属性，调用对象的方法，遍历整个对象的结构图，实现字段类型转化等功能。它使用相同的表达式去存取对象的属性。这样可以更好的取得数据。

　　webwork2和现在的Struts2.x中使用OGNL取代原来的EL来做界面数据绑定，所谓界面数据绑定，也就是把界面元素（例如一个textfield,hidden)和对象层某个类的某个属性绑定在一起，修改和显示自动同步。

　　WebWork表现层采用JSP,用WebWork标签库来支持OGNL表达式，其中我们比较常用输出对象的符号包括三个：# $ %。那么使用场景是怎么样的呢？

　　“#”用途：

　　访问的对象是OGNL上下文和Action上下文，#相当于ActionContext.getContext()；是一种以map形式进行取值的用法。

比如在action实例中进行定义的时候

<span style="font-family:Microsoft YaHei;font-size:14px;"><strong>/* 列表显示 */
    publicString list() throwsException {
 
       List<Role>roleList = roleService.findAll();
       // 将获取到的列表值放到值栈里面
       ActionContext.getContext().put("roleList",roleList);
       return "list";
 
    }</strong></span>

　　此时我们将值放在了map中，在jsp页面用表达式进行获取的时候是(以Struts2进行讲解)：

　　<s:iteratorvalue="#roleList">，此时获取到map中的值时我们用的是#；

　　OGNL上下文实际上就是一个Map对象，由ognl.OgnlContext类表示。它里面可以存放很多个JavaBean对象。它有一个上下文根对象。

　　上下文中的根对象可以直接使用名来访问或直接使用它的属性名访问它的属性值。否则要加前缀“#key”。可能有人说这个不是一个根对象吗？为什么是用#roleList。

　　分下面的情况，值得注意的是：

　　　1.如果需要引用valueStack中的值，需要使用这样的形式。

　　　<s:iteratorvalue="# roleList " /> //userList在action部分被保存在Request中，所以使用#加属性名来引用值。

　　　2.如果集合的值是通过action的方法，假设我们的action中有一个getListMenu方法，返回一个List集合。

　　　我们可以使用如下的形式来引用这个集合，并用s:iterator来输出。

　　　<s:iteratorvalue="listMenu" />

　　“$“用途

　　在Struts 2配置文件中，引用OGNL表达式，经常会使用这个符号，比如页面的跳转需要添加完毕再次返回上一级页面，此时我们就需要配置相应的父ID了。

       <!--部门管理-->
       <action name="department_*" class="departmentAction" method="{1}">
           <result name="list">/WEB-INF/jsp/departmentAction/list.jsp</result>
           <result name="saveUI">/WEB-INF/jsp/departmentAction/saveUI.jsp</result>
           <result name="toList" type="redirectAction">department_list?parentId=${parentId}</result>
       </action>

　　department_list?parentId=${parentId}用户返回到上一级的页面。