所谓自动装配,即让 Spring 自动管理 Bean 与 Bean 之间的依赖关系,无须使用 ref 显式指定依赖 Bean 。Spring 容器会自动检查 XML 配置文件的内容,为主调 Bean 注入依赖 Bean 。自动装配可以减少配置文件的工作量,但会降低依赖关系的透明性和清晰性。
通过使用自动装配,可以让 Spring 插件自动将业务逻辑组件注入 Struts2 的 Action 实例中。
<?xml version="1.0" encoding="GBK"?> <!-- 指定Struts2配置文件的DTD信息 --> <!DOCTYPE struts PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 2.0//EN" "http://struts.apache.org/dtds/struts-2.0.dtd"> <!-- Struts2配置文件的根元素 --> <struts> <!-- 配置了系列常量 --> <constant name="struts.custom.i18n.resources" value="messageResource"/> <constant name="struts.i18n.encoding" value="GBK"/> <package name="lee" extends="struts-default"> <!-- 定义处理用户请求的Action,指定该Action的实现类--> <action name="login" class="lee.LoginAction"> <!-- 为两个逻辑视图配置视图页面 --> <result name="error">/error.jsp</result> <result name="success">/welcome.jsp</result> </action> <!-- 让用户直接访问该应用时列出所有视图页面 --> <action name=""> <result>.</result> </action> </package> </struts>
些时 Struts2 配置文件里配置的依然是该 Action 的实现类,该配置文件与不整合 Spring 时的配置文件没有任何区别。
注意:整合 Spring 框架与不整合时的区别并不是在这个配置文件中体现,而是在创建该 Action 实例时体现出来的。如果不整合 Spring 框架,则 Struts2 框架负责创建 Action 实例,创建成功后就结束了;如果整合 Spring 框架,则当 Action 实例创建完成后,Spring 插件还会负责将该 Action 所需的业务逻辑组件注入给该 Action 实例。
查看刚才的 Action 代码,发现了如下方法定义:
//系统所用的业务逻辑组件 private MyService ms; //设置注入业务逻辑组件所必需的setter方法 public void setMs(MyService ms) { this.ms = ms; }
通过上面的 setter 方法,可以看出该 Action 所需的业务逻辑组件名为 ms ,因此我们必须在配置业务逻辑组件时,指定其 id 属性为 ms 。本示例应用的 applicationContext.xml 文件代码如下:
<?xml version="1.0" encoding="GBK"?> <!-- 指定Spring配置文件的DTD信息 --> <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 2.0//EN" "http://www.springframework.org/dtd/spring-beans-2.0.dtd"> <!-- Spring配置文件的根元素 --> <beans> <!-- 配置一个业务逻辑组件,实现类为lee.MyServiceImp --> <bean id="ms" class="lee.MyServiceImpl"/> </beans>
因为在配置业务逻辑组件时,指定了该业务逻辑组件的 id 为 ms ,则 Spring 插件可以在创建 Action 实例时将该业务逻辑组件注入给 Action 实例。
在这种整合策略下,Spring 插件负责为 Action 自动装配业务逻辑组件,从而可以简化配置文件的配置。这种方式也存在如下两个缺点:
- Action 与业务逻辑组件的耦合降低了代码层次,必须在配置文件中配置 Action 所需控制器同名的业务逻辑组件。这不利于高层次解耦。
- Action 接受 Spring 容器的自动装配,代码的可读性较差。