Spring 的依賴注入（DI）
前言
歡迎來到本篇文章，書接上回，本篇說說 Spring 中的依賴注入，包括注入的方式，寫法，該選擇哪個注入方式以及可能出現的迴圈依賴問題等內容。
如果正在閱讀的朋友還不清楚什麼是「依賴」，建議先看看我第一篇文章，通過 Employee 和 Department 簡單說了什麼是所謂的依賴。
什麼是依賴注入？
依賴注入是一個過程，舉個例子：
public class A {
private B b;
// 省略 getter 和 setter
// 省略構造方法
}
現在 A 類 是依賴 B 類的，沒有 B，A 什麼都不是。Spring IoC 容器建立好 B 的範例物件後並賦值給 A 物件中的 b 屬性（成員變數）的過程，就是所謂的「依賴注入」。
當然，這也是所謂的控制反轉了，物件 b 的建立不是我們手動 new 建立的，而是 Spring IoC 容器建立的。
使用 DI 原則，可以讓程式碼更加簡潔，當物件提供其依賴項時，解耦也更加有效。依賴項 B 注入給 A 的範例物件，A 的範例物件是不會查詢它的依賴項 B 的，也不知道依賴項 B 的位置。
依賴注入主要有兩種實現方式：基於構造方法的依賴注入和基於 Setter 的依賴注入。
基於構造方法的依賴注入
基於構造方法的 DI 是通過 Spring IoC 容器呼叫帶有許多引數的構造方法來完成的，每個參數列示一個依賴項。這與上一篇中呼叫具有特定引數的靜態工廠方法來構造 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，沒什麼特別之處，最普通不過的類了，沒有繼承或者實現 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 類相結合，才能發揮 Spring IoC 的作用。
現在假設 B 和 C 是沒有任何繼承上的關聯，也沒有任何潛在的歧義，那麼我們在設定後設資料中的設定是正常的，需要使用到 <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，這時候歧義就出現了，它是布林型別還是字串型別呢？這就需要由我們來告訴 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 開始的，來解決引數型別出現歧義的情況。
<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 的無參構造方法或者無參的靜態工廠方法範例化了 Bean 之後，再來呼叫 Bean 的 Setter 方法來實現的。
下面這個依舊是普通的 Java Bean，當然你加上相關業務邏輯，就不是純粹的 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
}
// 業務邏輯，有關 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 來實現這些屬性的注入。但是，我們基本不會這樣用，而是使用 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 物件不可變，並且確保需要的依賴不為空。此外，構造方法注入的依賴總是能夠在返回使用者端（呼叫方）的時候保證完全初始化的狀態。
-
對於可選的弱依賴項，使用基於 Setter 的 DI。當使用
@Autowired註解，並將註解用到 Setter 方法上的話，那麼這個 Setter 設定的屬性就變成強依賴了。
對於構造方法進行 DI ，其中：
- 依賴不可變：其實說的就是 final 關鍵字。
- 依賴不為空：省去了我們對注入的 Bean 的檢查，當要範例化 Bean 的時候，由於自己實現了有引數的構造方法，所以不會呼叫預設構造方法，那麼就需要 Spring IoC 容器傳入所需要的引數給有參構造方法，所以就兩種情況，有該型別的引數傳入，那麼 OK ；無該型別的引數，那麼報錯。
- 完全初始化的狀態：這個可以跟上面的依賴不為空結合起來，向構造方法傳參之前，要確保注入的內容不為空，那麼肯定要呼叫依賴物件的構造方法完成範例化。而在 Java 類載入範例化的過程中，構造方法是最後一步才執行的，所以返回來的範例化物件都是完全初始化之後的狀態。
依賴的處理過程
Spring IoC 容器按如下方式執行 Bean 的依賴處理（Dependency Resolution Process，個人認為把 Resolution 理解成處理，解決等意思比較好）。
- 根據設定後設資料的內容，
ApplicationContext被建立和初始化。這個設定後設資料是用來描述所有 Bean 的，它可以是 XML、Java 程式碼或註解。 - 對於每個 Bean 來說，它的依賴是以屬性、構造方法引數或靜態工廠方法的引數（如果你用它代替構造方法）的形式表達的。在 Spring IoC 建立 Bean 的時候，這些依賴會被提供給需要的 Bean。
- 每個屬性或構造方法引數都是要設定的值的實際定義，或對容器中另一個 Bean 的參照。
- 每個作為值的屬性或構造方法引數都會從其指定格式轉換為該屬性或構造方法引數的實際型別。預設情況下，Spring 可以將以字串格式提供的值轉換為所有內建型別，如
int、long、String、boolean等等。
當 Spring IoC 容器被建立時，Spring IoC 容器一開始就會校驗每個 Bean 的設定。在建立 Bean 之前，Bean 的屬性本身不會被設定。
而且當容器被建立時，那些具有單例作用域的 Bean 也預設會被建立。對於其他情況的 Bean，只有在被請求時才會建立。
一個 Bean 的建立是有可能導致一堆 Bean 被建立，這一堆的 Bean 被稱為 Bean 圖（a graph of beans），因為 Bean 與 Bean 之間可能存在相互依賴，如同社會中的人一樣，都有相關的聯絡，所以形成 Bean 圖。
Bean 作用域在進行 Bean 定義的時候可以進行定義，使用
scope屬性即可定義 Bean 的作用域。
迴圈依賴
當你使用建構函式注入的時候，某種情況下可能產生一個無法解決的迴圈依賴問題。那什麼是迴圈依賴？
舉個例子：
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 類的一個物件，這種情況就是所謂的迴圈依賴，A 和 B 之間相互依賴。
A 和 B 之間的迴圈依賴關係會迫使其中一個 Bean 在未完全初始化之前，被注入到另一個 Bean 中。
這時候，Spring IoC 容器會在執行時檢測到這種迴圈的參照，並丟擲一個 BeanCurrentlyInCreationException。
有一種解決方案就是：修改 A 類或者 B 類的原始碼，使其通過 Setter 方式注入依賴項。
當然，一般情況下，我們可以完全相信 Spring，Spring 會在容器載入時檢測設定問題，如檢查參照不存在的 Bean 或迴圈依賴等。它會盡量晚地設定 Bean 的屬性以及處理依賴的關係。
假設當你請求一個物件時，如果在建立該物件或其依賴關係時出現問題，已經正確載入的 Spring 容器就會產生異常。所以，這意味著我們需要提前發現這些問題。
預設情況下，ApplicationContext 會預先範例化單例 Bean，所以在建立 Spring IoC 容器時會花費一些時間和記憶體。但好處是可以在容器建立時發現設定問題，而不是在後續出現。
如果不存在迴圈依賴關係，一個 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 中有兩種方式來實現，一種是基於構造方法的 DI，另一種是基於 Setter 的DI。當然，網上講到的依賴注入，還有好幾種方式，目前對於我們來說，知道這兩種就 OK。
對於這兩種 DI，我們也說了如何選擇，具體看官網的說法，推薦的是基於構造方法的 DI，當然，具體問題具體分析，有時候是需要用到基於 Setter 的 DI 的，比如解決迴圈依賴的時候。
接著也說了依賴的處理過程，簡單點就是 Spring 會先根據設定後設資料去建立 ApplicationContext 這個作為 Spring IoC 容器，在容器建立時，會驗證 Bean 是否正確設定了，預設單例的 Bean 會先被建立等等等的處理。同時可能遇到迴圈依賴的問題，一種解決方案就是將某一個 Bean 使用 Setter 的方式注入依賴項。
以上，便是本篇文章的內容了。下期咱們講講依賴注入的一些細節寫法，比如有的依賴項是集合，那麼設定後設資料中該如何寫這個集合，進而實現集合的依賴注入等等。
希望本篇有幫助到大家，有興趣的話可以關注我，關注這個系列！
最後的最後
希望各位螢幕前的靚仔靚女們給個三連！你輕輕地點了個贊，那將在我的心裡世界增添一顆明亮而耀眼的星！
咱們下期再見！