DI - 代码天地

跟开涛学Spring

DI:

Spring IoC容器注入依赖资源主要有以下两种基本实现方式：

构造器注入：就是容器实例化Bean时注入那些依赖，通过在在Bean定义中指定构造器参数进行注入依赖，包括实例工厂方法参数注入依赖，但静态工厂方法参数不允许注入依赖；

一、根据参数索引注入

<constructor-arg index="1" value="1"/>

二、根据参数类型进行注入

<constructor-arg type="java.lang.String" value="Hello World!"/>

类名必须为全限定类名如java.lang.String，int

三、根据参数名进行注入

<constructor-arg name="message" value="Hello World!"/>

四、在构造器上使用 @java.beans.ConstructorProperties({"message"}) 注解来指定参数名

构造器注入时，需确保编译时class文件包含“变量信息”，具体查看编译时是否包含“变量调试信息”请右击项目，在弹出的对话框选择属性；然后在弹出的对话框选择“Java Compiler”条目，在“Class 文件生成”框中选择“添加变量信息到Class文件（调试器使用）

有一点需要大家注意就是静态工厂方式和实例工厂方式根据参数名字注入的方式只支持通过在class文件中添加“变量调试信息”方式才能运行，ConstructorProperties注解方式不能工作，它只对构造器方式起作用，不建议使用根据参数名进行构造器注入。

setter注入：通过setter方法进行注入依赖；

public class BooleanTestBean {

private boolean success;

public void setSuccess(boolean success) {

this.success = success;

}

public boolean isSuccess() {

return success;

}

</bean>

Spring容器目前能对各种基本类型把配置的String参数转换为需要的类型。

注：Spring类型转换系统对于boolean类型进行了容错处理，除了可以使用“true/false”标准的Java值进行注入，还能使用“yes/no”、“on/off”、“1/0”来代表“真/假”，所以大家在学习或工作中遇到这种类似问题不要觉得是人家配置错了，而是Spring容错做的非常好。

注入Bean ID:

...

注入集合:

注入List 、Set

<bean id="listBean" class="cn.javass.spring.chapter3.bean.ListTestBean">  
		    <property name="values">  
			<list>  
			    <value>1</value>  
			    <value>2</value>  			    
			</list>  
		   </property>  
		</bean>  
		
		<bean id="setBean" class="cn.javass.spring.chapter3.bean.SetTestBean">  
		     <property name="values">  
			<set>  
			<value>1</value>  
			<value>2</value>  			
			</set>  
		     </property>  
		</bean>

注入Collection

因为Collection类型是Set和List类型的基类型，所以使用<set>或<list>标签都可以进行注入

注入数组类型:

使用<array>标签来配置注入

注入字典（Map）类型:

使用<map>标签来配置注入，其属性“key-type”和“value-type”分别指定“键”和“值”的数据类型

默认都为String

Properties注入:

使用<props>标签

引用其它Bean:

构造器注入、Setter注入

属性： <property id="" ref="bean"/>

标签： <property id="">

</proterty>

其他方式：

<ref local=””/>配置方式：用于引用通过<bean id=”beanName”>方式中通过id属性指定的Bean，它能利用XML解析器的验证功能在读取配置文件时来验证引用的Bean是否存在。因此如果在当前配置文件中有相互引用的Bean可以采用<ref local>方式从而如果配置错误能在开发调试时就发现错误。

<ref parent=””/>：

用于引用父容器中的Bean，不会引用当前容器中的Bean，当然父容器中的Bean和当前容器的Bean是可以重名的，获取顺序是直接到父容器找。

内部Bean定义：

内部Bean就是在<property>或<constructor-arg>内通过<bean>标签定义的Bean，该Bean不管是否指定id或name，对其他外部Bean都不可见，

DI 扩展

循环依赖：

总结：

出现循环引用的时候，使用setter方式调用无参的构造器创建对象即可避免死循环

补充：出现循环依赖是设计上的问题，一定要避免！

请参考《敏捷软件开发：原则、模式与实践》中的“无环依赖”原则

包之间的依赖结构必须是一个直接的无环图形（DAG）。也就是说，在依赖结构中不允许出现环（循环依赖）。

lazy-init：

延迟初始化Bean

Spring容器会在创建容器时提前初始化“singleton”作用域的Bean，“singleton”就是单例的意思即整个容器每个Bean只有一个实例。

Spring容器预先初始化Bean通常能帮助我们提前发现配置错误，所以如果没有什么情况建议开启，除非有某个Bean可能需要加载很大资源，而且很可能在整个应用程序生命周期中很可能使用不到，可以设置为延迟初始化。

延迟初始化的Bean通常会在第一次使用时被初始化；或者在被非延迟初始化Bean作为依赖对象注入时在会随着初始化该Bean时被初始化，因为在这时使用了延迟初始化Bean。

depends-on：

depends-on是指指定Bean初始化及销毁时的顺序，使用depends-on属性指定的Bean要先初始化完毕后才初始化当前Bean，由于只有“singleton”Bean能被Spring管理销毁，所以当指定的Bean都是“singleton”时，使用depends-on属性指定的Bean要在指定的Bean之后销毁。

<property name="file" value="D:/test.txt"/>配置：Spring容器能自动把字符串转换为java.io.File。

init-method="init" ：指定初始化方法，在构造器注入和setter注入完毕后执行。

destroy-method="destroy"：指定销毁方法，只有“singleton”作用域能销毁，“prototype”作用域的一定不能，其他作用域不一定能；后边再介绍。

//一定要注册销毁回调，否则我们定义的销毁方法不执行

context.registerShutdownHook();

自动装配：

目前Spring3.0支持“no”、“byName”、“byType”、“constructor”四种自动装配，默认是“no”指不支持自动装配的，其中Spring3.0已不推荐使用之前版本的“autodetect”自动装配，推荐使用Java 5+支持的（@Autowired）注解方式代替；如果想支持“autodetect”自动装配，请将schema改为“spring-beans-2.5.xsd”或去掉。

自动装配的好处是减少构造器注入和setter注入配置，减少配置文件的长度。自动装配通过配置<bean>标签的“autowire”属性来改变自动装配方式。

可以采用在“<beans>”标签中通过“default-autowire”属性指定全局的自动装配方式，即如果default-autowire=”byName”，将对所有Bean进行根据名字进行自动装配。

byName：

通过设置Bean定义属性autowire="byName"，意思是根据名字进行自动装配，只能用于setter注入。

比如我们有方法“setHelloApi”，则“byName”方式Spring容器将查找名字为helloApi的Bean并注入，如果找不到指定的Bean，将什么也不注入。

是不是不要配置<property>了，如果一个bean有很多setter注入，通过“byName”方式是不是能减少很多<property>配置。

此处注意了，在根据名字注入时，将把当前Bean自己排除在外：比如“hello”Bean类定义了“setHello”方法，则hello是不能注入到“setHello”的。

byType：

通过设置Bean定义属性autowire="byType"，意思是指根据类型注入，用于setter注入

比如如果指定自动装配方式为“byType”，而“setHelloApi”方法需要注入HelloApi类型数据，则Spring容器将查找HelloApi类型数据，如果找到一个则注入该Bean，如果找不到将什么也不注入，如果找到多个Bean将优先注入<bean>标签“primary”属性为true的Bean，否则抛出异常来表明有个多个Bean发现但不知道使用哪个

在根据类型注入时，将把当前Bean自己排除在外

根据类型找到多个Bean时，对于集合类型（如List、Set）将注入所有匹配的候选者

也可：

1、通过设置Bean的“autowire-candidate”属性为false来把指定Bean后自动装配候选者中移除

<bean class="cn.javass.spring.chapter2.helloworld.HelloImpl"

autowire-candidate="false"/>

<bean id="bean1" class="cn.javass.spring.chapter3.bean.HelloApiDecorator"

autowire="byType"/>

2、通过设置Bean定义的“primary”属性为true来把指定自动装配时候选者中首选Bean：

<bean class="cn.javass.spring.chapter2.helloworld.HelloImpl"

primary="true"/>

<bean id="bean" class="cn.javass.spring.chapter3.bean.HelloApiDecorator"

autowire="byType"/>

constructor:

通过设置Bean定义属性autowire="constructor"，功能和“byType”功能一样，根据类型注入构造器参数

<bean id="bean"

class="cn.javass.spring.chapter3.bean.HelloApiDecorator"

autowire="constructor"/>

autodetect：

自动检测是使用“constructor”还是“byType”自动装配方式，已不推荐使用。如果Bean有空构造器那么将采用“byType”自动装配方式，否则使用“constructor”自动装配方式。此处要把3.0的xsd替换为2.5的xsd，否则会报错。

不是所有类型都能自动装配：

不能自动装配的数据类型：Object、基本数据类型（Date、CharSequence、Number、URI、URL、Class、int）等；

通过“<beans>”标签default-autowire-candidates属性指定的匹配模式，不匹配的将不能作为自动装配的候选者，例如指定“*Service，*Dao”，将只把匹配这些模式的Bean作为候选者，而不匹配的不会作为候选者；

通过将“<bean>”标签的autowire-candidate属性可被设为false，从而该Bean将不会作为依赖注入的候选者。

数组、集合、字典类型的根据类型自动装配和普通类型的自动装配是有区别的：

数组类型、集合（Set、Collection、List）接口类型：

将根据泛型获取匹配的所有候选者并注入到数组或集合中，如“List<HelloApi> list”将选择所有的HelloApi类型Bean并注入到list中，而对于集合的具体类型将只选择一个候选者，“如 ArrayList<HelloApi> list”将选择一个类型为ArrayList的Bean注入，而不是选择所有的HelloApi类型Bean进行注入；

字典（Map）接口类型：

同样根据泛型信息注入，键必须为String类型的Bean名字，值根据泛型信息获取，如“Map<String, HelloApi> map” 将选择所有的HelloApi类型Bean并注入到map中，而对于具体字典类型如“HashMap<String, HelloApi> map”将只选择类型为HashMap的Bean注入，而不是选择所有的HelloApi类型Bean进行注入。

自动装配缺点：

最重要的缺点就是没有了配置，在查找注入错误时非常麻烦，还有比如基本类型没法完成自动装配，所以可能经常发生一些莫名其妙的错误，

在此我推荐大家不要使用该方式，最好是指定明确的注入方式，或者采用最新的Java5+注解注入方式。所以大家在使用自动装配时应该考虑自己负责项目的复杂度来进行衡量是否选择自动装配方式。

自动装配注入方式能和配置注入方式一同工作吗？

当然可以，大家只需记住配置注入的数据会覆盖自动装配注入的数据。

大家是否注意到对于采用自动装配方式时如果没找到合适的的Bean时什么也不做，这样在程序中总会莫名其妙的发生一些空指针异常，而且是在程序运行期间才能发现，有没有办法能在提前发现这些错误呢？接下来就让我来看下依赖检查吧。

依赖检查：

用于检查Bean定义的属性都注入数据了，不管是自动装配的还是配置方式注入的都能检查，如果没有注入数据将报错，从而提前发现注入错误，只检查具有setter方法的属性。

Spring3+也不推荐配置方式依赖检查了，建议采用Java5+ @Required注解方式，测试时请将XML schema降低为2.5版本的，和自动装配中“autodetect”配置方式的xsd一样。

一、none：默认方式，表示不检查；

二、objects

检查除基本类型外的依赖对象

三、simple

对基本类型进行依赖检查，包括数组类型，其他依赖不报错

四、all：

对所以类型进行依赖检查

<bean id="bean" class="cn.javass.spring.chapter3.bean.HelloApiDecorator"

dependency-check="objects">

</bean>

===========================================================================

以下方法注入比较难懂，需要仔细分析：

方法注入

所谓方法注入其实就是通过配置方式覆盖或拦截指定的方法，通常通过代理模式实现。Spring提供两种方法注入：查找方法注入和方法替换注入。

因为Spring是通过CGLIB动态代理方式实现方法注入，也就是通过动态修改类的字节码来实现的，本质就是生成需方法注入的类的子类方式实现。

在进行测试之前，我们需要确保将“com.springsource.cn.sf.cglib-2.2.0.jar”放到lib里并添加到“Java Build Path”中的Libararies中。否则报错，异常中包含“nested exception is java.lang.NoClassDefFoundError: cn/sf/cglib/proxy/CallbackFilter”。

传统方式和Spring容器管理方式唯一不同的是不需要我们手动生成子类，而是通过配置方式来实现；其中如果要替换createPrinter()方法的返回值就使用查找方法注入；如果想完全替换sayHello()方法体就使用方法替换注入。接下来让我们看看具体实现吧。

一、查找方法注入：又称为Lookup方法注入，用于注入方法返回结果，也就是说能通过配置方式替换方法返回结果。使用<lookup-method name="方法名" bean="bean名字"/>配置；其中name属性指定方法名，bean属性指定方法需返回的Bean。

方法定义格式：访问级别必须是public或protected，保证能被子类重载，可以是抽象方法，必须有返回值，必须是无参数方法，查找方法的类和被重载的方法必须为非final：

<public|protected> [abstract] <return-type> theMethodName(no-arguments);

因为“singleton”Bean在容器中只有一个实例，而“prototype”Bean是每次获取容器都返回一个全新的实例，所以如果“singleton”Bean在使用“prototype” Bean情况时，那么“prototype”Bean由于是“singleton”Bean的一个字段属性，所以获取的这个“prototype”Bean就和它所在的“singleton”Bean具有同样的生命周期，所以不是我们所期待的结果。因此查找方法注入就是用于解决这个问题。

1）首先定义我们需要的类，Printer类是一个有状态的类，counter字段记录访问次数：

java代码：

 
    查看 
    复制到剪贴板 
    打印 
   
package cn.javass.spring.chapter3.bean;  
public class Printer {  
    private int counter = 0;  
    public void print(String type) {  
        System.out.println(type + " printer: " + counter++);  
    }  
}  

HelloImpl5类用于打印欢迎信息，其中包括setter注入和方法注入，此处特别需要注意的是该类是抽象的，充分说明了需要容器对其进行子类化处理，还定义了一个抽象方法createPrototypePrinter用于创建“prototype”Bean，createSingletonPrinter方法用于创建“singleton”Bean，此处注意方法会被Spring拦截，不会执行方法体代码：

java代码：

 
    查看 
    复制到剪贴板 
    打印 
   
package cn.javass.spring.chapter3;  
import cn.javass.spring.chapter2.helloworld.HelloApi;  
import cn.javass.spring.chapter3.bean.Printer;  
public abstract class HelloImpl5 implements HelloApi {  
    private Printer printer;  
    public void sayHello() {  
        printer.print("setter");  
        createPrototypePrinter().print("prototype");  
        createSingletonPrinter().print("singleton");
    }  
    public abstract Printer createPrototypePrinter();  
    public Printer createSingletonPrinter() {  
        System.out.println("该方法不会被执行，如果输出就错了");  
        return new Printer();  
    }  
    public void setPrinter(Printer printer) {  
        this.printer = printer;  
    }  
}  

2）开始配置了，配置文件在（resources/chapter3/lookupMethodInject.xml），其中“prototypePrinter”是“prototype”Printer，“singletonPrinter”是“singleton”Printer，“helloApi1”是“singleton”Bean，而“helloApi2”注入了“prototype”Bean：

java代码：

 
    查看 
    复制到剪贴板 
    打印 
   
<bean id="prototypePrinter"  
class="cn.javass.spring.chapter3.bean.Printer" scope="prototype"/>  
<bean id="singletonPrinter"  
class="cn.javass.spring.chapter3.bean.Printer" scope="singleton"/>  
<bean id="helloApi1" class="cn.javass.spring.chapter3.HelloImpl5" scope="singleton">  
<property name="printer" ref="prototypePrinter"/>  
<lookup-method name="createPrototypePrinter" bean="prototypePrinter"/>  
<lookup-method name="createSingletonPrinter" bean="singletonPrinter"/>  
</bean>      
      
<bean id="helloApi2" class="cn.javass.spring.chapter3.HelloImpl5" scope="prototype">  
<property name="printer" ref="prototypePrinter"/>  
<lookup-method name="createPrototypePrinter" bean="prototypePrinter"/>  
<lookup-method name="createSingletonPrinter" bean="singletonPrinter"/>  
</bean>            

（helloApi1此处helloApi1的printer好像是注入错了，应该是singletonPrinter吧）

3）测试代码如下：

java代码：

 
    查看 
    复制到剪贴板 
    打印 
   
package cn.javass.spring.chapter3;  
import org.junit.Test;  
import org.springframework.context.support.ClassPathXmlApplicationContext;  
import cn.javass.spring.chapter2.helloworld.HelloApi;  
public class MethodInjectTest {  
@Test  
public void testLookup() {  
ClassPathXmlApplicationContext context =  
new ClassPathXmlApplicationContext("chapter3/lookupMethodInject.xml");  
        System.out.println("=======singleton sayHello======");  
        HelloApi helloApi1 = context.getBean("helloApi1", HelloApi.class);  
        helloApi1.sayHello();  
        helloApi1 = context.getBean("helloApi1", HelloApi.class);  
        helloApi1.sayHello();  
        System.out.println("=======prototype sayHello======");  
        HelloApi helloApi2 = context.getBean("helloApi2", HelloApi.class);  
        helloApi2.sayHello();  
        helloApi2 = context.getBean("helloApi2", HelloApi.class);  
        helloApi2.sayHello();  
}}  

其中“helloApi1”测试中，其输出结果如下：

java代码：

 
    查看 
    复制到剪贴板 
    打印 
   
=======singleton sayHello======  
setter printer: 0  
prototype printer: 0  
singleton printer: 0  
setter printer: 1  
prototype printer: 0  
singleton printer: 1  

首先“helloApi1”是“singleton”，通过setter注入的“printer”是“prototypePrinter”，所以它应该输出“setter printer:0”和“setter printer:1”；而“createPrototypePrinter”方法注入了“prototypePrinter”，所以应该输出两次“prototype printer:0”；而“createSingletonPrinter”注入了“singletonPrinter”，所以应该输出“singleton printer:0”和“singleton printer:1”。

而“helloApi2”测试中，其输出结果如下：

java代码：

 
    查看 
    复制到剪贴板 
    打印 
   
      
=======prototype sayHello======  
setter printer: 0  
prototype printer: 0  
singleton printer: 2  
setter printer: 0  
prototype printer: 0  
singleton printer: 3  
   

首先“helloApi2”是“prototype”，通过setter注入的“printer”是“prototypePrinter”，所以它应该输出两次“setter printer:0”；而“createPrototypePrinter”方法注入了“prototypePrinter”，所以应该输出两次“prototype printer:0”；而“createSingletonPrinter”注入了“singletonPrinter”，所以应该输出“singleton printer:2”和“singleton printer:3”。

大家是否注意到“createSingletonPrinter”方法应该输出“该方法不会被执行，如果输出就错了”，而实际是没输出的，这说明Spring拦截了该方法并使用注入的Bean替换了返回结果。

方法注入主要用于处理“singleton”作用域的Bean需要其他作用域的Bean时，采用Spring查找方法注入方式无需修改任何代码即能获取需要的其他作用域的Bean。

二、替换方法注入：也叫“MethodReplacer”注入，和查找注入方法不一样的是，他主要用来替换方法体。通过首先定义一个MethodReplacer接口实现，然后如下配置来实现：

java代码：

 
    查看 
    复制到剪贴板 
    打印 
   
<replaced-method name="方法名" replacer="MethodReplacer实现">  
<arg-type>参数类型</arg-type>  
</replaced-method>”  
   

1）首先定义MethodReplacer实现，完全替换掉被替换方法的方法体及返回值，其中reimplement方法重定义方法功能，参数obj为被替换方法的对象，method为被替换方法，args为方法参数；最需要注意的是不能再通过“method.invoke(obj, new String[]{"hehe"});” 反射形式再去调用原来方法，这样会产生循环调用；如果返回值类型为Void，请在实现中返回null：

java代码：

 
    查看 
    复制到剪贴板 
    打印 
   
package cn.javass.spring.chapter3.bean;  
import java.lang.reflect.Method;  
import org.springframework.beans.factory.support.MethodReplacer;  
public class PrinterReplacer implements MethodReplacer {  
    @Override  
    public Object reimplement(Object obj, Method method, Object[] args)   throws Throwable {  
        System.out.println("Print Replacer");  
        //注意此处不能再通过反射调用了,否则会产生循环调用，知道内存溢出  
        //method.invoke(obj, new String[]{"hehe"});  
        return null;  
    }  
}  

2）配置如下，首先定义MethodReplacer实现，使用< replaced-method >标签来指定要进行替换方法，属性name指定替换的方法名字，replacer指定该方法的重新实现者，子标签< arg-type >用来指定原来方法参数的类型，必须指定否则找不到原方法：

java代码：

 
    查看 
    复制到剪贴板 
    打印 
   
<bean id="replacer" class="cn.javass.spring.chapter3.bean.PrinterReplacer"/>  
<bean id="printer" class="cn.javass.spring.chapter3.bean.Printer">  
<replaced-method name="print" replacer="replacer">  
        <arg-type>java.lang.String</arg-type>  
    </replaced-method>  
</bean>  
   

3）测试代码将输出“Print Replacer ”，说明方法体确实被替换了：

java代码：

 
    查看 
    复制到剪贴板 
    打印 
   
@Test  
public void testMethodReplacer() {  
    ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("chapter3/methodReplacerInject.xml");  
    Printer printer = context.getBean("printer", Printer.class);  
    printer.print("我将被替换");  
}  

DI

方法注入

猜你喜欢