什么是依賴注入

依賴注入是一個過程，舉個例子：

public class A {
    private B b;
    // 省略 getter 和 setter
    // 省略構造方法
}

現(xiàn)在 A 類 是依賴 B 類的，沒有 B，A 什么都不是。Spring IoC 容器創(chuàng)建好 B 的實例對象后并賦值給 A 對象中的 b 屬性（成員變量）的過程，就是所謂的「依賴注入」。

當然，這也是所謂的控制反轉了，對象 b 的創(chuàng)建不是我們手動 new 創(chuàng)建的，而是 Spring IoC 容器創(chuàng)建的。

使用 DI 原則，可以讓代碼更加簡潔，當對象提供其依賴項時，解耦也更加有效。依賴項 B 注入給 A 的實例對象，A 的實例對象是不會查找它的依賴項 B 的，也不知道依賴項 B 的位置。

依賴注入主要有兩種實現(xiàn)方式：基于構造方法的依賴注入和基于 Setter 的依賴注入。

基于構造方法的依賴注入

基于構造方法的 DI 是通過 Spring IoC 容器調用帶有許多參數的構造方法來完成的，每個參數表示一個依賴項。這與上一篇中調用具有特定參數的靜態(tài)工廠方法來構造 Bean 是幾乎等價的。

public class Vehicle {
    // Vehicle 依賴于 Producer 對象，或者說 Vehicle 持有一個 Producer 依賴項
    private final Producer producer;
    // 構造方法，讓 Spring IoC 容器能夠注入 Producer 對象給 Vehicle 對象
    public Vehicle(Producer producer) {
        this.producer = producer;
    }
}

注意，這個 Vehicle 類就只是一個普通的 Java Bean，或者說 POJO，沒什么特別之處，最普通不過的類了，沒有繼承或者實現(xiàn) Spring 指定的任意類。

構造方法中參數的解析

Spring IoC 是通過構造方法參數的解析來匹配需要注入的依賴項。換句話說，解析實際上就是通過匹配參數的類型，來確定注入什么依賴項。

如果構造方法的參數中沒有存在潛在的歧義，那么在 Bean 被實例化的時候，構造方法中參數的順序和實例化時進行賦值是一樣的。

package cn.god23bin.demo.model;
public class A {
    private B b;
    private C c;
    public A(B b, C c) {
        this.b = b;
        this.c = c;
    }
}

單獨寫這些類，是完成不了依賴注入的，這時候需要配置元數據了，讓它與 Java 類相結合，才能發(fā)揮 Spring IoC 的作用。

現(xiàn)在假設 B 和 C 是沒有任何繼承上的關聯(lián)，也沒有任何潛在的歧義，那么我們在配置元數據中的配置是正常的，需要使用到 <constructor-arg/> 標簽，該標簽只需有一個 ref 屬性，即引用（reference），指明 A 的構造方法的參數為 B 和 C，如下：

<beans>
	<bean id="a" class="cn.god23bin.demo.model.A">
		<constructor-arg ref="b"/>
		<constructor-arg ref="c"/>
	</bean>
	<bean id="b" class="cn.god23bin.demo.model.B"/>
	<bean id="c" class="cn.god23bin.demo.model.C"/>
</beans>

我們知道，B 和 C 是屬于引用類型，類型是確切的，所以直接使用 ref 屬性。

如果是基本數據類型，那么賦值時，就可能會有歧義，Spring 不能確定這個值的類型，比如一個基本數據類型的值是 true，這時候歧義就出現(xiàn)了，它是布爾類型還是字符串類型呢？這就需要由我們來告訴 Spring 了，就需要使用 type 和 value 屬性來指定。

比如：

package cn.god23bin.demo.model;
public class D {
    private final int money;
    private final String power;
    public D(int money, String power) {
        this.money = money;
        this.power = power;
    }
}

<bean id="d" class="cn.god23bin.demo.model.D">
	<constructor-arg type="int" value="25000000"/>
	<constructor-arg type="java.lang.String" value="25"/>
</bean>

當然，除了使用 type 指定基本數據類型，還有兩個屬性可以解決歧義，分別是 index 和 name 屬性。

index 屬性：

使用 index 屬性指定構造方法參數的下標，下標是從 0 開始的，來解決參數類型出現(xiàn)歧義的情況。

<bean id="d" class="cn.god23bin.demo.model.D">
	<constructor-arg index="0" value="25000000"/>
	<constructor-arg index="1" value="25"/>
</bean>

name 屬性：

使用 name 屬性指定構造方法參數的名稱來解決歧義。

<bean id="d" class="cn.god23bin.demo.model.D">
	<constructor-arg name="money" value="25000000"/>
	<constructor-arg name="power" value="25"/>
</bean>

基于 Setter 的依賴注入

基于 Setter 的 DI，是在 Spring IoC 容器調用了 Bean 的無參構造方法或者無參的靜態(tài)工廠方法實例化了 Bean 之后，再來調用 Bean 的 Setter 方法來實現(xiàn)的。

下面這個依舊是普通的 Java Bean，當然你加上相關業(yè)務邏輯，就不是純粹的 Java Bean 了，不過 Spring 依舊能夠管理這種對象。

Vehicle：

public class Vehicle {
    // Vehicle 持有的 Producer 依賴項
    private Producer pro;
    // 同理
    private Author aut;
    // 同理
    private int money;
    // setter 方法，可以讓 Spring IoC 容器調用注入 Producer 對象
    public void setProducer(Producer pro) {
        this.pro = pro;
    }
    // 同理
    public void setAut(Author aut) {
        this.aut = aut;
    }
    // 同理
    public void setMoney(int money) {
        this.money = money
    }
    // 業(yè)務邏輯，有關 Producer 的...
}

對應的配置元數據：

<bean id="vehicle" class="cn.god23bin.demo.model.Vehicle">
    <!-- 使用 property 標簽的 ref 屬性注入引用類型的依賴項 -->
    <property name="pro" ref="producer"/>
    <!-- 使用內嵌 ref 標簽 注入 -->
    <property name="aut">
    	<ref bean="author"/>
    </property>
    <property name="money" value="255"/>
</bean>
<bean id="producer" class="cn.god23bin.demo.model.Producer"/>
<bean id="author" class="cn.god23bin.demo.model.Author"/>

Spring IoC 容器（ApplicationContext）支持基于構造方法的 DI 和基于 Setter 的 DI，也支持使用構造方法注入了一部分依賴項后，再使用 Setter 的方式注入其他的依賴項。

我們可以通過配置一個 BeanDefinition 和 PropertyEditor 來實現(xiàn)這些屬性的注入。但是，我們基本不會這樣用，而是使用 XML 的 Bean 定義，使用注解的 Bean 定義（比如 @Component，@Controller 等），又或者使用 @Bean 這種基于 Java 配置類的方式（@Configuration）來定義。

實際上，這些最終都會轉成 BeanDefinition 對象的并被 Spring IoC 使用。

選擇哪個 DI 方式

在代碼的編寫中，選擇使用構造方法注入還是使用 Setter 注入呢？

官網上是這么說的：

Since you can mix constructor-based and setter-based DI, it is a good rule of thumb to use constructors for mandatory dependencies and setter methods or configuration methods for optional dependencies. Note that use of the @Autowired annotation on a setter method can be used to make the property be a required dependency; however, constructor injection with programmatic validation of arguments is preferable.

The Spring team generally advocates constructor injection, as it lets you implement application components as immutable objects and ensures that required dependencies are not null. Furthermore, constructor-injected components are always returned to the client (calling) code in a fully initialized state. As a side note, a large number of constructor arguments is a bad code smell, implying that the class likely has too many responsibilities and should be refactored to better address proper separation of concerns.

Setter injection should primarily only be used for optional dependencies that can be assigned reasonable default values within the class. Otherwise, not-null checks must be performed everywhere the code uses the dependency. One benefit of setter injection is that setter methods make objects of that class amenable to reconfiguration or re-injection later. Management through JMX MBeans is therefore a compelling use case for setter injection.

Use the DI style that makes the most sense for a particular class. Sometimes, when dealing with third-party classes for which you do not have the source, the choice is made for you. For example, if a third-party class does not expose any setter methods, then constructor injection may be the only available form of DI.

簡而言之，Spring 團隊是推薦用構造方法來完成 DI 的。

• 對于強依賴項，直接用基于構造方法的 DI，這種注入方式能夠保證注入的 Bean 對象不可變，并且確保需要的依賴不為空。此外，構造方法注入的依賴總是能夠在返回**客戶端（調用方）**的時候保證完全初始化的狀態(tài)。
• 對于可選的弱依賴項，使用基于 Setter 的 DI。當使用 @Autowired 注解，并將注解用到 Setter 方法上的話，那么這個 Setter 設置的屬性就變成強依賴了。

對于構造方法進行 DI ，其中：

• 依賴不可變：其實說的就是 final 關鍵字。
• 依賴不為空：省去了我們對注入的 Bean 的檢查，當要實例化 Bean 的時候，由于自己實現(xiàn)了有參數的構造方法，所以不會調用默認構造方法，那么就需要 Spring IoC 容器傳入所需要的參數給有參構造方法，所以就兩種情況，有該類型的參數傳入，那么 OK ；無該類型的參數，那么報錯。
• 完全初始化的狀態(tài)：這個可以跟上面的依賴不為空結合起來，向構造方法傳參之前，要確保注入的內容不為空，那么肯定要調用依賴對象的構造方法完成實例化。而在 Java 類加載實例化的過程中，構造方法是最后一步才執(zhí)行的，所以返回來的實例化對象都是完全初始化之后的狀態(tài)。

依賴的處理過程

Spring IoC 容器按如下方式執(zhí)行 Bean 的依賴處理（Dependency Resolution Process，個人認為把 Resolution 理解成處理，解決等意思比較好）。

• 根據配置元數據的內容，ApplicationContext 被創(chuàng)建和初始化。這個配置元數據是用來描述所有 Bean 的，它可以是 XML、Java 代碼或注解。
• 對于每個 Bean 來說，它的依賴是以屬性、構造方法參數或靜態(tài)工廠方法的參數（如果你用它代替構造方法）的形式表達的。在 Spring IoC 創(chuàng)建 Bean 的時候，這些依賴會被提供給需要的 Bean。
• 每個屬性或構造方法參數都是要設置的值的實際定義，或對容器中另一個 Bean 的引用。
• 每個作為值的屬性或構造方法參數都會從其指定格式轉換為該屬性或構造方法參數的實際類型。默認情況下，Spring 可以將以字符串格式提供的值轉換為所有內置類型，如 int、long、String、boolean 等等。

當 Spring IoC 容器被創(chuàng)建時，Spring IoC 容器一開始就會校驗每個 Bean 的配置。在創(chuàng)建 Bean 之前，Bean 的屬性本身不會被設置。

而且當容器被創(chuàng)建時，那些具有單例作用域的 Bean 也默認會被創(chuàng)建。對于其他情況的 Bean，只有在被請求時才會創(chuàng)建。

一個 Bean 的創(chuàng)建是有可能導致一堆 Bean 被創(chuàng)建，這一堆的 Bean 被稱為 Bean 圖（a graph of beans），因為 Bean 與 Bean 之間可能存在相互依賴，如同社會中的人一樣，都有相關的聯(lián)系，所以形成 Bean 圖。

Bean 作用域在進行 Bean 定義的時候可以進行定義，使用 scope 屬性即可定義 Bean 的作用域。

循環(huán)依賴

當你使用構造函數注入的時候，某種情況下可能產生一個無法解決的循環(huán)依賴問題。那什么是循環(huán)依賴？

舉個例子：

public class A {
    private B b;
    public A(B b) {
        this.b = b;
    }
}

public class B {
    private A a;
    public B(A a){
        this.a = a;
    }
}

如上所示，A 類通過構造方法注入需要 B 類的對象，而 B 類也通過構造方法注入 A 類的一個對象，這種情況就是所謂的循環(huán)依賴，A 和 B 之間相互依賴。

A 和 B 之間的循環(huán)依賴關系會迫使其中一個 Bean 在未完全初始化之前，被注入到另一個 Bean 中。

這時候，Spring IoC 容器會在運行時檢測到這種循環(huán)的引用，并拋出一個 BeanCurrentlyInCreationException。

有一種解決方案就是：修改 A 類或者 B 類的源代碼，使其通過 Setter 方式注入依賴項。

當然，一般情況下，我們可以完全相信 Spring，Spring 會在容器加載時檢測配置問題，如檢查引用不存在的 Bean 或循環(huán)依賴等。它會盡量晚地設置 Bean 的屬性以及處理依賴的關系。

假設當你請求一個對象時，如果在創(chuàng)建該對象或其依賴關系時出現(xiàn)問題，已經正確加載的 Spring 容器就會產生異常。所以，這意味著我們需要提前發(fā)現(xiàn)這些問題。

默認情況下，ApplicationContext 會預先實例化單例 Bean，所以在創(chuàng)建 Spring IoC 容器時會花費一些時間和內存。但好處是可以在容器創(chuàng)建時發(fā)現(xiàn)配置問題，而不是在后續(xù)出現(xiàn)。

如果不存在循環(huán)依賴關系，一個 Bean 在被注入到另一個 Bean 之前會被完全配置。這意味著當 A 依賴于 B 時，Spring IoC 容器會先完全配置好 B（包括實例化 Bean、設置依賴關系和調用相關的生命周期方法），再調用 A 的 Setter 方法。

依賴注入示例

下面寫下示例，快速回顧下上面的兩種注入方式，幫助大家更好理解在以 XML 作為配置元數據的情況下，使用基于構造方法的 DI 和基于 Setter 的 DI。

基于構造方法的 DI：

package cn.god23bin.demo.service;
import cn.god23bin.demo.repository.UserRepository;
public class UserService {
    // UserService 的依賴項 UserRepository
	private UserRepository userRepository;
    // 使用構造方法進行 DI，將 UserRepository 注入到 UserService
	public UserService(UserRepository userRepository) {
    	this.userRepository = userRepository;
	}
}

<bean id="userService" class="cn.god23bin.demo.service.UserService">
   <constructor-arg ref="userRepository" />
</bean>
<bean id="userRepository" class="cn.god23bin.demo.repository.UserRepository" />

基于 Setter 的 DI：

package cn.god23bin.demo.service;
import cn.god23bin.demo.repository.UserRepository;
public class UserService {
	private UserRepository userRepository;
	public void setUserRepository(UserRepository userRepository) {
		this.userRepository = userRepository;
	}
}

<bean id="userService" class="cn.god23bin.demo.service.UserService">
   <property name="userRepository" ref="userRepository" />
</bean>
<bean id="userRepository" class="cn.god23bin.demo.repository.UserRepository" />

總結

本文開頭舉了個例子講了什么是依賴注入，實際上就是一個過程，把一個 Bean 注入到另一個 Bean 中的過程。

這個過程，在 Spring 中有兩種方式來實現(xiàn)，一種是基于構造方法的 DI，另一種是基于 Setter 的DI。當然，網上講到的依賴注入，還有好幾種方式，目前對于我們來說，知道這兩種就 OK。

對于這兩種 DI，我們也說了如何選擇，具體看官網的說法，推薦的是基于構造方法的 DI，當然，具體問題具體分析，有時候是需要用到基于 Setter 的 DI 的，比如解決循環(huán)依賴的時候。

接著也說了依賴的處理過程，簡單點就是 Spring 會先根據配置元數據去創(chuàng)建 ApplicationContext 這個作為 Spring IoC 容器，在容器創(chuàng)建時，會驗證 Bean 是否正確配置了，默認單例的 Bean 會先被創(chuàng)建等等等的處理。同時可能遇到循環(huán)依賴的問題，一種解決方案就是將某一個 Bean 使用 Setter 的方式注入依賴項。

以上就是深入了解Spring中的依賴注入DI的詳細內容，更多關于Spring依賴注入的資料請關注腳本之家其它相關文章！

最新評論