Spring整合Struts2

Spring整合Struts2
虽然Spring提供了自己的MVC组件，但一来Spring的MVC组件稍嫌烦琐，二来struts2的拥护者实在太多。

1：启动Spring容器
对于使用Spring的web应用，无须手动创建Spring容器，而是通过配置文件，声明地创建Spring容器。因此在Web应用中创建Spring容器有如下二种方式：
->：直接在web.xml文件中配置创建Spring容器。
->: 利用第三方MVC框架的扩展点，创建Spring容器。
其实第一种方式创建Spring容器的方式更加常见。为了让Spring容器随Web应用的启动而自动启动，借助于ServletContextListener监听器即可完成，该监听器可以在Web应用启动时回调自定义方法-该方法就可以启动Spring容器。
Spring提供了一个ContextLoaderListener，该监听器类实现了ServletContextListener接口。该类可以作为Listener使用，它会在创建时自动查找WEB-INF/下的applicationContext.xml文件，因此，如果只有一个配置文件，并且文件名为applicationContext.xml，则只需要web.xml文件中增加如下配置片段即可。
<listener>
<listener-class>
org.springframeword.web.context.ContextLoaderListener
</listener-class>
</listener>
如果有多个配置文件需要载入，则考虑使用<context-param.../>元素来确定配置文件的文件名。ContextLoaderListener加载时，会查找名为contextConfigLoaction的初始化参数。因此，配置<context-param.../>时应指定参数名为contextConfigLocation.
<!--指定多个配置文件 -->
<context-param>
<!-- 参数名为contextConfigLocation -->
<param-name>contextConfigLocation</param-name>
<param-value>
/WEB-INF/daoContext.xml
,/WEB-INF/applicationContext.xml
</param-value>
</context-param>
<!-- 使用ContextLoaderListener 初始化Spring容器 -->
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
Spring根据指定配置文件创建WebApplicationContext对象，并将其保存在Web应用的ServletContext中。大部分情况下，应用中的Bean无须感受到ApplicationContext的存在，只要利用ApplicationContext的IoC即可。
如果需要在应用中获取ApplicationContext实例，则可以通过如下代码获取。
//获取当前Web应用的Spring容器
WebApplicationContext ctx = WebApplicationContextUtils.getWebApplicationContext(servletContext);
当然，也可以通过ServletContext的getAttribute方法获取ApplicationContext。但使用WebApplicationContextUtils类更方便，因为这样无须记住ApplicationContext在ServletContext中的属性名(属性名为WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE)。

MVC框架与Spring整合的思考
对于一个基于B/S架构的Java EE 应用而言，用户请求总是向MVC框架的控制器请求，而当控制器拦截用于请求后，必须调用义务逻辑组件来处理用户请求。此时有一个问题：控制器应该如何获得业务逻辑组件?
最容易想到的策略是，直接通过new关键字创建业务逻辑组件，然后调用业务逻辑组件的方法，根据业务逻辑方法的返回值确定结果。
在实际的应用中，很少见到采用上面的访问策略，因为这是一个非常差的策略。不这样做至少有如下三个原因:
->:控制器直接创建业务逻辑组件，导致控制器和业务逻辑组件的耦合降低到代码层次，不利于高层解耦。
->:控制器不应该负责义务逻辑组件的创建，控制器只是业务逻辑组件的使用者，无须关系业务逻辑组件的实现。
->:每次创建新的业务逻辑组件导致性能降低。
答案是采用工程模式，或者服务定位器模式。对于采用服务定位模式，是远程访问的场景。在这种场景下，业务逻辑组件已经在某个容器中运行，并对于提供某种服务。控制器无须理会该业务逻辑组件的创建，直接调用该服务即可，但在调用之间，必须先找到该服务-这是服务定位器的概念。经典Java EE 应用就是这种结构的应用。
对于轻量级的Java EE 应用，工厂模式则是更加实际的策略。因为在轻量级Java EE应用中，业务逻辑组件不是EJB，通常就是一个POJO，业务逻辑组件的生成通常应由工程负责，而且工厂可以保证该组件的实例只需要一个就够了，可以避免重复实例化造成的系统开销。

采用工厂模式，将控制器与业务逻辑组件的实现分离，从而提供更好的解耦。在采用工厂模式的访问策略中，所有的业务逻辑组件创建有工厂负责，业务逻辑组件的运行也由工厂负责。而控制器只需要定位工厂实例即可。
如果系统采用Spring框架，则Spring成为最大的工厂。Spring负责业务逻辑组件的创建和生成，并可管理业务逻辑组件的生命周期。可以如此理解：Spring是个性能非常优秀的工厂，可以生产所有的实例，从业务逻辑组件，到持久层组件，甚至控制器组件。
现在的问题是：控制器如何访问到Spring容器中的业务逻辑组件呢？
为了让Action访问到Spring的业务逻辑组件，二种策略：
->:Spring容器负责管理控制器Action，并利用依赖注入为控制器注入业务逻辑组件。
->:利用Spring的自动装配，Action将自动从Spring容器中获取所需的业务逻辑组件。
让Spring管理控制器
让Spring容器来管理应用中的控制器，可以充分利用Spring的IoC特性，但需要将配置Struts2的控制器部署在Spring容器中，因此导致配置文件冗余。
正如前面所介绍的，Struts2的核心控制器首先拦截到用于请求，然后将请求转发给相应的Action处理，在此过程中，Struts2将创建Action实例，并调用其execute()方法，这个过程是固定的(除非改写Struts2的核心控制器)。现在的情形是：我们已经把Action实例交由Spring容器来管理，而不是由Struts2产生的。那么，核心控制器如何知道调用Spring容器中的Action，而不是自行创建Actoin实例呢？这个工作由Struts2提供的Spring插件完成。
Spring插件提供了一种伪Action，当我们在struts.xml中配置Action时，通常需要指定class属性，该属性就是用于创建Action实例的实现类。但Spring插件允许我们指定class属性时，不再指定Action实际实现类，而是指定为Spring容器中的Bean ID，这样Struts2不再创建自己负责创建Action实例，而是直接通过Spring容器中获取Action对象。
通过上面的方式，我们发现这种整合策略的关键：当Struts2将请求转发给指定的Action时，Struts2中的该Action只是一个"傀儡"，它只有一个代号，并没有指定实际的实现类，当然也不可能创建Action实例，而隐藏在该Action下的Spring容器中Action实例-它才是真正处理用户请求的控制器。
这种整合流程的组件写作图如图：
图：
如上面的图所示，struts2只是配置一个伪控制器，这个伪控制器的功能实际由Spring容器分钟的控制器来完成，这就实现了让核心控制器调用Spring容器中的Action来处理用于请求。
在这种整合策略下，处理用户请求的Action有Spring插件负责创建，但Spring插件创建Action实例时，并不是利用配置Action时指定的class属性来创建该Action实例，而是从Spring容器中取出对应的Bean实例完成创建。