Spring IOC三種注入方式:
1. 接口注入
2. getter，setter方式注入
3. 構造器注入
對象與對象之間的關系可以簡單的理解為對象之間的依賴關系:
A類需要B類的一個實例來進行某些操作,比如在A類的方法中需要調用B類的方法來完成功能,叫做A類依賴於B類.
控制反轉是一種將組件依賴關系的創建和管理置於程序外部的技術,由容器控制程序之間的關系,而不是由代碼直接控制.
1.接口注入
public class ClassA {
private InterfaceB clzB;
public void doSomething() {
Ojbect obj = Class.forName(Config.BImplementation).newInstance();
clzB = (InterfaceB)obj;
clzB.doIt();
}
……
}
上面代碼中,ClassA依賴於InterfaceB的實現,如何獲得InterfaceB實現類的實例?傳統的方法是在代碼中創建 InterfaceB實現類的實例,並將賦予clzB.這樣一來,ClassA在編譯期即依賴於InterfaceB的實現.為了將調用者與實現者在編譯 期分離,於是有了上面的代碼.
我們根據預先在配置文件中設定的實現類的類名(Config.BImplementation),動態加載實現類,並通過InterfaceB強制轉型后為ClassA所用,這就是接口注入的一個最原始的雛形.
public class ClassA {
private InterfaceB clzB;
public Object doSomething(InterfaceB b) {
clzB = b;
return clzB.doIt();
}
……
}
上面代碼中,加載接口實現並創建其實例的工作由容器完成.
在運行期,InterfaceB實例將由容器提供.即使在IOC的概念尚未確立時,這樣的方法也已經頻繁出現在我們的代碼中.
public class MyServlet extends HttpServlet {
public void doGet(HttpServletRequest request,HttpServletResponse response)throws ServletException, IOException {
……
}
}
HttpServletRequest和HttpServletResponse實例由Servlet Container在運行期動態注入.
2.Setter設置注入
基於設置模式的依賴注入機制更加直觀,也更加自然.
public class ClassA {
private InterfaceB clzB;
public void setClzB(InterfaceB clzB) {
this.clzB = clzB;
}
……
}
3.構造器注入
public class DIByConstructor {
private final DataSource dataSource;
public DIByConstructor(DataSource ds) {
this.dataSource = ds;
}
……
}
構造器注入,即通過構造函數完成依賴關系的設定,容器通過調用類的構造方法將其所需的依賴關系注入其中.
三種注入方式比較:
接口注入：
接口注入模式因為具備侵入性，它要求組件必須與特定的接口相關聯，因此並不被看好，實際使用有限。
Setter 注入：
對於習慣了傳統 javabean 開發的程序員，通過 setter 方法設定依賴關系更加直觀。
如果依賴關系較為復雜，那么構造子注入模式的構造函數也會相當龐大，而此時設值注入模式則更為簡潔。
如果用到了第三方類庫，可能要求我們的組件提供一個默認的構造函數，此時構造子注入模式也不適用。
構造器注入：
在構造期間完成一個完整的、合法的對象。
所有依賴關系在構造函數中集中呈現。
依賴關系在構造時由容器一次性設定，組件被創建之后一直處於相對“不變”的穩定狀態。
只有組件的創建者關心其內部依賴關系，對調用者而言，該依賴關系處於“黑盒”之中。
總結
Spring使用注入方式，為什么使用注入方式，這系列問題實際歸結起來就是一句話，Spring的注入和IoC（本人關於IoC的闡述）反轉控制是一回事。
理論上：第三種注入方式（構造函數注入）在符合java使用原則上更加合理，第二種注入方式（setter注入）作為補充。
實際上：我個人認為第二種注入方式（setter注入）可以取得更加直觀的效果，在使用工作上有不可比擬的優勢，所以setter注入依賴關系應用更加廣泛。