Struts2杂谈

看看Struts-2的处理流程：  

1)   Browser产生一个请求并提交框架来处理：根据配置决定使用哪些拦截器、action类和结果等。  

2)   请求经过一系列拦截器：根据请求的级别不同拦截器做不同的处理。这和Struts-1的RequestProcessor类很相似。  

3)   调用Action:       产生一个新的action实例，调用业务逻辑方法。  

4)   调用产生结果：匹配result       class并调用产生实例。  

5)   请求再次经过一系列拦截器返回：过程也可配置减少拦截器数量  

6)   请求返回用户：从control返回servlet，生成Html。  

 

这里很明显的一点是不存在FormBean的作用域封装，直接可以从Action中取得数据。       这里有一个Strut-2配置的web.xml文件：  

<filter>      

   <filter-name>   controller   </filter-name>      

   <filter-class> org.apache.struts.action2.dispatcher.FilterDispatcher   </filter-class>  

</filter>  

<filter-mapping>      

   <filter-name>   cotroller   </filter-name>      

   <url-pattern>   /*   </url-pattern>  

</filter-mapping>  

注意到以往的servlet变成了filter，ActionServlet变成了FilterDispatcher，*.do变成了/*。filter 配置定义了名称(供关联)和filter的类。Filter mapping让URI匹配成功的的请求调用该filter。默认情况下，扩展名为".action"。这个是在default.properties文件里的"struts.action.extension"属性定义的。default.properties是属性定义文件，通过在项目classpath路径中包含一个名为“struts.properties”的文件来设置不同的属性值。而Struts-2的默认配置文件名为struts.xml。由于1和2的action扩展名分别为.do和.action，所以很方便能共存。我们再来看一个Struts-2的action代码：  

        public   class   MyAction   {  

              public   String   execute()   throws   Exception   {      

                      //do   the   work      

                      return   "success   ";  

              }  

        }  

很明显的区别是不用再继承任何类和接口，返回的只是一个String，无参数。实际上在Struts-2中任何返回String的无参数方法都可以通过配置来调用action。所有的参数从哪里来获得呢？答案就是Inversion of Control技术（控制反转）。笔者尽量以最通俗的方式来解释，我们先试图让这个Action获得reuqest对象，这样可以提取页面提交的任何参数。那么我们把request设为一个成员变量，然后需要一个对它的set方法。由于大部分的action都需要这么做，我们把这个set方法作为接口来实现。  

        public   interface   ServletRequestAware   {  

                public   void   setServletRequest(HttpServletRequest   request);  

        }  

 

        public   class   MyAction   implements   ServletRequestAware   {      

                private   HttpServletRequest   request;      

 

                public   void   setServletRequest(HttpServletRequest   request)  {      

                        this.request   =   request;      

                }  

                               

                public   String   execute()   throws   Exception       {  

                          return       Action.SUCCESS;      

                }      

        }  

那么谁来调用这个set方法呢？也就是说谁来控制这个action的行为，以往我们都是自己在适当的地方写上一句 action.setServletRequest(…)，也就是控制权在程序员这边。然而控制反转的思想是在哪里调用交给正在运行的容器来决定，只要利用Java反射机制来获得Method对象然后调用它的invoke方法传入参数就能做到，这样控制权就从程序员这边转移到了容器那边。程序员可以减轻很多繁琐的工作更多的关注业务逻辑。Request可以这样注入到action中，其他任何对象也都可以。为了保证action的成员变量线程安全， Struts-2的action不是单例的，每一个新的请求都会产生一个新的action实例。  

那么有人会问，到底谁来做这个对象的注入工作呢？答案就是拦截器。拦截器又是什么东西？笔者再来尽量通俗的解释拦截器的概念。大家要理解拦截器的话，首先一定要理解GOF23种设计模式中的Proxy模式。  

A对象要调用f()，它希望代理给B来做，那么B就要获得A对象的引用，然后在B的f()中通过A对象引用调用A对象的f()方法，最终达到A的f()被调用的目的。有没有人会觉得这样很麻烦，为什么明明只要A.f()就可以完成的一定要封装到B的f()方法中去？有哪些好处呢？  

1)   这里我们只有一个A，当我们有很多个A的时候，只需要监视B一个对象的f()方法就可以从全局上控制所有被调用的f()方法。  

2)   另外，既然代理人B能获得A对象的引用，那么B可以决定在真正调A对象的f()方法之前可以做哪些前置工作，调完返回前可有做哪些后置工作。  

讲到这里，大家看出来一点拦截器的概念了么？它拦截下一调f()方法的请求，然后统一的做处理（处理每个的方式还可以不同，解析A对象就可以辨别），处理完毕再放行。这样像不像对流动的河水横切了一刀，对所有想通过的水分子进行搜身，然后再放行？这也就是AOP（Aspect  of  Programming面向切面编程）的思想。  

Anyway，Struts-2只是利用了AOP和IoC技术来减轻action和框架的耦合关系，力图到最大程度重用action的目的。在这样的技术促动下，Struts-2的action成了一个简单被框架使用的POJO（Plain Old Java Object）罢了。实事上AOP和IoC的思想已经遍布新出来的每一个框架上，他们并不是多么新的技术，利用的也都是JDK早已可以最到的事情，它们代表的是更加面向接口编程，提高重用，增加扩展性的一种思想。Struts-2只是部分的使用这两种思想来设计完成的，另外一个最近很火的框架 Spring，更大程度上代表了这两种设计思想。