1.4.1.依赖注入 · Spring

依赖注入（DI）是一个处理对象的依赖的过程，换句话说就是处理与某个对象一起工作的其它对象。所依赖的对象可以通过构造参数、工厂方法参数以及设置对象实例的属性来定义。当一个对象被创建时，IOC 容器会注入它的依赖，这个过程与传统创建对象的方式是相反的故称为控制反转（IOC）。 &emsp; 使用DI后代码十分的简洁，并且在定义依赖时也能有效的解耦。对象不需要过多的去关注它依赖的对象，所以类更容易测试，特别是依赖于接口或者是抽象类时，可以在单元测试中使用stub或者mock实现。 &emsp; DI存在两种主要的形式：基于构造器注入和Setter方法注入。 * * * * * &emsp; ### **基于构造器注入** 构造注入通过容器提供指定的参数调用构造方法来完成，每个参数都称为依赖。这和通过提供给静态的工厂方法的参数来创建对象几乎是等价的。下面的样例展示了一个类通过构造方法来完成依赖注入的过程。 ~~~ public class SimpleMovieLister { // SimpleMovieLister依赖于MovieFinder private MovieFinder movieFinder; // Spring通过构造器注入MovieFinder实例 public SimpleMovieLister(MovieFinder movieFinder) { this.movieFinder = movieFinder; } //使用被注入MovieFinder实例来完成的业务逻辑已被忽略 } ~~~ 注意：这个类是普通的Java对象，不依赖于容器相关的接口、基类或者注解。 ### **构造参数的识别** 构造参数的识别是通过类型匹配来完成的，如果没有模糊不清的构造参数，那么构造参数的定义顺序就是容器实例化Bean时提供参数给构造器的顺序。参考如下代码： ~~~ package x.y; public class Foo { public Foo(Bar bar, Baz baz) { // ... } } ~~~ 现在，参数都是明确的。假定`Bar`和`Baz`没有继承关系，因此下面的配置没有任何问题，你也不需要在`<constructor-arg/>`元素中指定参数的索引和类型。 ~~~ <beans> <bean id="foo" class="x.y.Foo"> <constructor-arg ref="bar"/> <constructor-arg ref="baz"/> </bean> <bean id="bar" class="x.y.Bar"/> <bean id="baz" class="x.y.Baz"/> </beans> ~~~ 当引用的Bean的类型是确定的，这能很好的进行参数匹配。如果使用的是简单类型，比如：`<value>true</value>`，Spring就不能判断其类型了，所以不能独自完成类型匹配。参考如下代码： ~~~ package examples; public class ExampleBean { //计算最终答案的年份 private int years; //生活、宇宙、万物的答案 private String ultimateAnswer; public ExampleBean(int years, String ultimateAnswer) { this.years = years; this.ultimateAnswer = ultimateAnswer; } } ~~~ ##### 1.构造参数类型匹配在上面的例子中，如果你通过`type`属性指定参数的类型，那么容器可以很好的进行简单参数类型的类型匹配。参考如下代码： ~~~ <bean id="exampleBean" class="examples.ExampleBean"> <constructor-arg type="int" value="7500000"/> <constructor-arg type="java.lang.String" value="42"/> </bean> ~~~ ##### 2.构造参数索引使用`index`属性指定参数在构造器中的索引，参考如下代码： ~~~ <bean id="exampleBean" class="examples.ExampleBean"> <constructor-arg index="0" value="7500000"/> <constructor-arg index="1" value="42"/> </bean> ~~~ > 如果不指定index的值，则默认以<constructor-arg/>出现的顺序为参数索引。为了解决多个简单类型间的歧义性，可以通过指定值在构造参数中的索引。注意：索引从0开始。 ##### *3.构造参数名* 你也可以指定值所对应构造器中的参数名来消除歧义： ~~~ <bean id="exampleBean" class="examples.ExampleBean"> <constructor-arg name="years" value="7500000"/> <constructor-arg name="ultimateAnswer" value="42"/> </bean> ~~~ 注意：要使上述样例正常工作，必须启用调试标记来编译代码，这样Spring才能从构造器中查找到参数名。否则你必须使用`@ConstructorProperties` JDK注解来显式指定参数名，参考如下代码： ~~~ package examples; public class ExampleBean { // 忽略属性 @ConstructorProperties({"years", "ultimateAnswer"}) public ExampleBean(int years, String ultimateAnswer) { this.years = years; this.ultimateAnswer = ultimateAnswer; } } ~~~ ***** &emsp; ### **基于Setter方法注入** 容器通过无参构造方法或者无参静态工厂方法实例化Bean之后，再通过调用Setter方法来完成依赖注入。下面的样例展示了一个类通过Setter方法来完成依赖注入。注意：这个类是普通的Java对象，不依赖于容器相关的接口、基类或者注解。 ~~~ public class SimpleMovieLister { // SimpleMovieLister依赖于MovieFinder private MovieFinder movieFinder; // Spring通过Setter方法注入MovieFinder实例 public void setMovieFinder(MovieFinder movieFinder) { this.movieFinder = movieFinder; } //使用被注入MovieFinder实例来完成的业务逻辑已被忽略 } ~~~ `ApplicationContext`支持构造注入和Setter方法注入，也支持通过构造参数注入某些依赖后再通过Setter注入其它依赖。配置的依赖存在于`BeanDefinition`中，可以结合`PropertyEditor`完成属性的转换。然而，大多开发者并不会直接使用这些类（即以编程的方式）而是使用XML、被注解的组件（即被`@Component`、 `@Controller`注解的类）以及带有`@Configuration`的类中`@Bean`注解的方法来定义Bean，这些配置在内部被转换为`BeanDefinition`实例并被用来加载整个Spring IOC容器。 <p style="margin-bottom:0px">&emsp;</p> >### :-: **使用构造注入还是Setter方法注入？** > > 尽管可以使用混合注入，但是通过**构造方法完成必要依赖的注入**，通过**Setter方法完成可选依赖的注入**是一个好的编程方式。注意：在Setter方法上标注`@Required`（[1.9.1.@Required](1.9.1.Required.md)）注解使得属性为必需依赖。不过，使用构造注入(带有编程式参数验证)更可取。 > **Spring团队提倡使用构造注入**，原因如下： > 1.该方式可以使得依赖为不可变对象并且不会为空； > 2.通过构造注入的依赖的对象被客户端调用时都是完全初始化好的； > 3.它还可以作为启示：过多的构造参数是一种不好的编程方式，意味着此类拥有过多的职责，最好重构代码，将多余的职责分离开来。 > &emsp; > Setter注入主要用于可选依赖，但是在类中也应该分配合理的默认值，否则在客户端使用此依赖时需要做非空检查。使用Setter注入有一个好处：可以重新配置或者重新注入依赖。通过JMX mbean进行管理是Setter注入的一个引人注目的用例。 > DI只在大多场景下是有效的，当处理没有源码的第三方类时，可以选择其它注入方式。比如：第三方类没有暴露任何Setter方法，那只能通过构造注入了。 ***** &emsp; ### **依赖处理过程** 容器处理依赖的的细节如下： * ` ApplicationContext`通过配置元数据来创建和初始化，配置元数据可以通过XML、Java代码、注解来指定。 * 每个Bean的依赖都表示为：属性、构造参数、静态工厂方法参数。当Bean创建后容器会注入其依赖。 * 每个属性、构造参数都是需要设置的值或者需要引用容器中的其它Bean。 * 每个属性、构造参数的值都被从指定的类型转换成实际类型。默认情况下，Spring可以将字符串类型的值转换为`int`，`long`，`String`，`boolean`等。 Spring容器被创建时会验证每个Bean的配置，然而Bean的属性在Bean没有创建之前不会设置。Bean默认是单例的并且会在容器创建时初始化（关于Bean的作用域将在[1.5.Bean的范围](1.5.Bean的范围.md)详细解释），非单例的Bean将会在被客户请求获取时创建。Bean的创建可能会一系列Bean（Bean的依赖的依赖......的依赖）被创建。注意，这些依赖项之间的不匹配解析可能在较晚的时候才出现，例如在第一次创建受影响的Bean时。 <p style="margin-bottom:0px">&emsp;</p> >### :-: **循环依赖** >如果通过构造器完成依赖注入，这可能会出现循环依赖的情况。 > >比如：类A通过构造注入类B的实例，而类B也通过构造注入类A的实例。容器在运行时会检查出循环引用并抛出`BeanCurrentlyInCreationException`。 >&emsp; >一个可行的解决方案：编辑源码将一些类的构造注入替换成Setter注入。此外，还可以避免使用构造注入而只使用Setter注入。换而言之，可以通过Setter注入配置循环依赖，虽然这是不推荐的。 >&emsp; >和典型的场景（没有循环依赖）不同，Bean A和Bean B之间的循环依赖关系迫使在完全初始化之前将其中一个Bean注入到另一个Bean中，这是一个矛盾的问题（这就像一个经典的问题：先有鸡还是先有蛋）。 > 开发者可以信任Spring做的事都是正确的。在容器加载时会检查不存在依赖和循环依赖等问题。当一个Bean被创建时，Spring会尽可能晚的设置属性和解析依赖。这意味着Spring容器被正确的加载后，当你请求一个对象时，如果创建该对象或者它的一项依赖出现问题，生成异常也会更晚。例如：当Bean的属性缺失或者无效时会抛出异常。所以一些配置问题可能延迟可见，这也就是为什么`ApplicationContext`的实现默认提前实例化单例Bean的原因。在容器创建之时花费一些时间和内存创建Bean可以提前发现问题。你仍然可以覆盖提前初始化的行为，将单例Bean的提前加载转变为延迟加载。 &emsp; 如果没有循环依赖存在，一个Bean在注入到依赖Bean之前就已经完成初始化好了。这意味着，如果Bean A依赖Bean B，在调用Bean A 的Setter方法之前，Bean B已是完全可用的。换而言之，当一个Bean初始化完成时，它的依赖已经设置好了，相关的生命周期方法（比如：初始化回调方法，详情参见：[1.6.1.生命周期回调函数](1.6.1.生命周期回调函数.md)）也调用完毕。 ***** &emsp; ### **依赖注入的例子** 下面的样例展示了基于XML配置的Setter注入。 ~~~ <bean id="exampleBean" class="examples.ExampleBean">  <property name="beanOne"> <ref bean="anotherExampleBean"/> </property>  <property name="beanTwo" ref="yetAnotherBean"/> <property name="integerProperty" value="1"/> </bean> <bean id="anotherExampleBean" class="examples.AnotherBean"/> <bean id="yetAnotherBean" class="examples.YetAnotherBean"/> ~~~ ~~~ public class ExampleBean { private AnotherBean beanOne; private YetAnotherBean beanTwo; private int i; public void setBeanOne(AnotherBean beanOne) { this.beanOne = beanOne; } public void setBeanTwo(YetAnotherBean beanTwo) { this.beanTwo = beanTwo; } public void setIntegerProperty(int i) { this.i = i; } } ~~~ 在上面的样例中，Setter方法和和`<property/>`对应。下面的样例采用构造注入。 ~~~ <bean id="exampleBean" class="examples.ExampleBean">  <constructor-arg> <ref bean="anotherExampleBean"/> </constructor-arg>  <constructor-arg ref="yetAnotherBean"/> <constructor-arg type="int" value="1"/> </bean> <bean id="anotherExampleBean" class="examples.AnotherBean"/> <bean id="yetAnotherBean" class="examples.YetAnotherBean"/> ~~~ ~~~ public class ExampleBean { private AnotherBean beanOne; private YetAnotherBean beanTwo; private int i; public ExampleBean( AnotherBean anotherBean, YetAnotherBean yetAnotherBean, int i) { this.beanOne = anotherBean; this.beanTwo = yetAnotherBean; this.i = i; } } ~~~ Bean定义指定的构造器参数会作为ExampleBean构造器中的参数。现在请参考另一个例子，Spring通过静态工厂来代替构造器创建实例。 ~~~ <bean id="exampleBean" class="examples.ExampleBean" factory-method="createInstance"> <constructor-arg ref="anotherExampleBean"/> <constructor-arg ref="yetAnotherBean"/> <constructor-arg value="1"/> </bean> <bean id="anotherExampleBean" class="examples.AnotherBean"/> <bean id="yetAnotherBean" class="examples.YetAnotherBean"/> ~~~ ~~~ public class ExampleBean { // 私有构造器 private ExampleBean(...) { ... } /** * 静态工厂方法； * 这个方法的参数可以被认为是待创建Bean的依赖项， * 不管这些参数实际是如何使用的的。 */ public static ExampleBean createInstance (AnotherBean anotherBean, YetAnotherBean yetAnotherBean, int i) { ExampleBean eb = new ExampleBean (...); // 其它操作...... return eb; } } ~~~ `<constructor-arg/>`提供给静态工厂方法的参数和构造器实际使用的参数是一致的。从工厂方法返回的对象类型可以和包含静态工厂方法的类不一致，尽管在本例子中是一致的。实例（非静态）工厂方法的用法和静态工厂方法本质上是一样（使用`factory-bean` 代替`class`属性），故不再此详述。