struts2整合spring的思路

　　

　　struts2整合spring有有两种策略:

　　》sping容器负责管理控制器Action,并利用依赖注入为控制器注入业务逻辑组件。

　　》利用spring的自动装配，Action将自动会从Spring容器中获取所需的业务逻辑组件。

 

　　让Spring管理控制器：

　　我们知道struts2的核心控制器首先拦截到用户请求，然后将请求转发给对应的Action处理，在此过程中,Struts2将负责创建Action实例，并调用相应的方法，这个过程是固定的（除非改写struts2的核心控制器）。现在的情形是：我们已经把Action实例交由Spring容器来管理，而不是由struts2产生的。那么，核心控制器如何知道调用Spring容器中的Action，而不是自行创建Action实例呢？这个工作是由struts2提供的spring插件完成的。

　　当我们在struts.xml文件中配置Action时，通常需要指定class属性，该属性就是用于创建Action实例的实现类。但Spring插件允许我们指定class属性时，不再指定Action的实例实际实现类，而是指定为Spring容器中的Bean ID,这样struts2不再自己负责创建Action实例，而是直接通过Spring容器去获取Action对象。

 

 

　　》使用自动装配:

　　在这种策略下，Action还是由Spring插件创建，Spring插件创建Action实例时，利用Spring的自动装配策略，将对应业务逻辑组件注入Action实例。

　　如果我们不指定自动装配，则系统默认使用按name自动装配。所谓自动装配，即让Spring自动管理Bean与Bean之间的依赖关系，无须使用ref显式指定依赖Bean。Spring容器会自动检查XML配置文件内容，为主Bean注入依赖Bean。自动装配可减少配置文件的工作量，但会降低依赖关系的透明性和清晰性。

　　通过设置struts.objectFactory.spring.autoWrite常量可以改变Spring插件的自动装配策略，该常量可接受如下几个值：

　　》name：根据属性名自动装配。Spring插件会查找容器中全部Bean，找出其中id属性与action所需业务逻辑组件同名的bean。将该bean实例注入到action实例。

　　》type：根据类型自动装配。Spring插件会查找容器中全部Bean，找出其中类型恰好与action所需业务逻辑组件相同的bean。将该bean实例注入到action实例。如果有多个这样的Bean,就会抛出一个致命异常；如果没有匹配的bean，则什么都不发生。

　　》auto：spring插件自动检测需要那种自动装配方式。

　　》constructor：与type类似，区别是constructor使用构造器来构造注入的所需参数，而不是使用设值注入方式。

　　使用spring插件自动注入的方式struts.xml和Action类不需要做什么修改。

 

　　

　　使用第二种方式好像与不整合没什么区别，肯定存在区别，只是这个区别不是在配置文件中体现，而是在创建该Action实例时体现出来。如果不整合spring框架，则struts2框架负责创建Action实例，创建成功后接结束了；如果整合spring框架，则当Action实例创建完成之后，Spring插件还会负责将该Action所需的业务逻辑组件注入给该Action