爲什麼使用IOC容器
先從IOC說起，這個概念其實是從我們平常new一個對象的對立面來說的，我們平常使用對象的時候，一般都是直接使用關鍵字類new一個對象，那這樣有什麼壞處呢？其實很顯然的，使用new那麼就表示當前模塊已經不知不覺的和new的對象耦合了，而我們通常都是更高層次的抽象模塊調用底層的實現模塊，這樣也就產生了模塊依賴於具體的實現，這樣與我們JAVA中提倡的面向接口面向抽象編程是相沖突的，而且這樣做也帶來系統的模塊架構問題。很簡單的例子，我們在進行數據庫操作的時候，總是業務層調用DAO層，當然我們的DAO一般都是會採用接口開發，這在一定程度上滿足了松耦合，使業務邏輯層不依賴於具體的數據庫DAO層。但是我們在使用的時候還是會new一個特定數據庫的DAO層，這無形中也與特定的數據庫綁定了，雖然我們可以使用抽象工廠模式來獲取DAO實現類，但除非我們一次性把所有數據庫的DAO寫出來，否則在進行數據庫遷移的時候我們還是得修改DAO工廠類。
那我們使用IOC能達到什麼呢？IOC，就是DAO接口的實現不再是業務邏輯層調用工廠類去獲取，而是通過容器（比如spring）來自動的爲我們的業務層設置DAO的實現類。這樣整個過程就反過來，以前是我們業務層主動去獲取DAO，而現在是DAO主動被設置到業務邏輯層中來了，這也就是反轉控制的由來。通過IOC，我們就可以在不修改任何代碼的情況下，無縫的實現數據庫的換庫遷移，當然前提還是必須得寫一個實現特定數據庫的DAO。我們把DAO普遍到更多的情況下，那麼IOC就爲我們帶來更大的方便性，比如一個接口的多個實現，我們只需要配置一下就ok了，而不需要再一個個的寫工廠來來獲取了。這就是IOC爲我們帶來的模塊的松耦合和應用的便利性。
說白了其實就是由我們平常的new轉成了使用反射來獲取類的實例。