Sping三種注入方式

                                                                       (本文摘自夏昕：開發指南)

依賴注入的三種實現形式

我們將組件的依賴關系由容器實現，那么容器如何知道一個組件依賴哪些其它的組件呢？這些回調方法會告知容器它所依賴的組件。根據回調方法的不同，我們可以將IoC分為三種形式：

1、 接口注入

 簡單的說，接口注入就是在運行期，加載接口實現并創建其實例的工作由容器完成。

如下面這個類:

public class ClassA {

private InterfaceB clzB;

   public Object doSomething(InterfaceB b) {

     clzB = b;

      return clzB.doIt();

    }

 ……

}

在運行期，InterfaceB實例將由容器提供。

Type1型IOC發展較早（有意或無意） ，在實際中得到了普遍應用，即使在IOC的概念尚未確立時，這樣的

方法也已經頻繁出現在我們的代碼中。

下面的代碼大家應該非常熟悉：

public class MyServlet extends HttpServlet {

 public void doGet(

HttpServletRequest request, 

HttpServletResponse response)

     throws ServletException, IOException {

   ……

 }

}   SpringFrameWork Developer’s Guide Version 0.6

這也是一個Type1 型注入，HttpServletRequest和HttpServletResponse實例由Servlet Container

在運行期動態注入。

另，Apache Avalon是一個較為典型的Type1型IOC容器。

2、 設置注入

在各種類型的依賴注入模式中，設值注入模式在實際開發中得到了最廣泛的應用（其中很大一部分得力于Spring框架的影響）。

基于設置模式的依賴注入機制更加直觀、也更加自然。前面的用戶注冊示例，就是典

型的設置注入，即通過類的setter方法完成依賴關系的設置。

3、 構造子函數注入

Type3 構造子注入

 構造子注入，即通過構造函數完成依賴關系的設定，如：

public class DIByConstructor {

   private final DataSource dataSource;

   private final String message;

   public DIByConstructor(DataSource ds, String msg) {

     this.dataSource = ds;

     this.message = msg;

    }

 ……

}

 可以看到，在Type3類型的依賴注入機制中，依賴關系是通過類構造函數建立，容器通過調用類的構

造方法，將其所需的依賴關系注入其中。

 PicoContainer （另一種實現了依賴注入模式的輕量級容器） 首先實現了Type3類型的依賴注入模式

.幾種依賴注入模式的對比總結

接口注入模式因為歷史較為悠久，在很多容器中都已經得到應用。但由于其在靈活性、易用性上不如其他兩種注入模式，因而在IOC的專題世界內并不被看好。

Type2和Type3型的依賴注入實現則是目前主流的IOC實現模式。這兩種實現方式各有特點，也各具優勢（一句經典廢話） 。

 Type2 設值注入的優勢

1． 對于習慣了傳統JavaBean開發的程序員而言，通過setter方法設定依賴關系顯得更加直

觀，更加自然。

2． 如果依賴關系（或繼承關系）較為復雜，那么Type3模式的構造函數也會相當龐大（我們需

要在構造函數中設定所有依賴關系） ，此時Type2模式往往更為簡潔。

3． 對于某些第三方類庫而言，可能要求我們的組件必須提供一個默認的構造函數（如Struts

中的Action） ，此時Type3類型的依賴注入機制就體現出其局限性，難以完成我們期望的功

能。

Type3 構造子注入的優勢：

1． “在構造期即創建一個完整、合法的對象” ，對于這條Java設計原則，Type3無疑是最好的

響應者。

2． 避免了繁瑣的setter方法的編寫，所有依賴關系均在構造函數中設定，依賴關系集中呈現，

更加易讀。

3． 由于沒有setter方法，依賴關系在構造時由容器一次性設定，因此組件在被創建之后即處于

相對“不變”的穩定狀態，無需擔心上層代碼在調用過程中執行setter方法對組件依賴關系

產生破壞，特別是對于Singleton模式的組件而言，這可能對整個系統產生重大的影響。

4． 同樣，由于關聯關系僅在構造函數中表達，只有組件創建者需要關心組件內部的依賴關系。

對調用者而言，組件中的依賴關系處于黑盒之中。對上層屏蔽不必要的信息，也為系統的

層次清晰性提供了保證。

5． 通過構造子注入，意味著我們可以在構造函數中決定依賴關系的注入順序，對于一個大量

依賴外部服務的組件而言，依賴關系的獲得順序可能非常重要，比如某個依賴關系注入的

先決條件是組件的DataSource及相關資源已經被設定。

可見，Type3和Type2模式各有千秋，而Spring、PicoContainer都對Type3和Type2類型的依賴注入機制提供了良好支持。這也就為我們提供了更多的選擇余地。理論上，以Type3類型為主，輔之以Type2類型機制作為補充，可以達到最好的依賴注入效果，不過對于基于Spring Framework開發的應用而言，Type2使用更加廣泛。