說實話，我對spring技術還是不算很了解，ioc的技術我在實體框架技術中提到過，但ioc和aop作為spring技術的兩個核心思想，我覺得在總結之前，還是有必要說明一下我所理解的ioc.
我們知道，如果兩個事務之間存在邏輯關係，而且你需要根據這個邏輯關係做事，(比如類a和類b，類a需要呼叫類b的方法，比如orm等)，那麼該做的事情，其實一件都不會少的，只是我們可以利用一些技術手段來減少直接的依賴或者叫硬**依賴。ioc的核心其實就是利用輔助配置資訊和程式語言提供的反射機制來替代這種硬關聯，舉個例子：
inte***ce ib;
public class b1:ib;
public class b2:ib;
ib是乙個介面，實現這個介面的類有2個：b1和b2，如果類a要呼叫這個介面，那麼介面必須有乙個例項來支援，我們看看幾種用法：
為了說明簡單，我們假設程式中只需要使用其中乙個b類。
第1種方式（直接使用）：
根據配置資訊來建立b
ib theib = new b1(),或者ib theib = new b2(),
然後呼叫我們需要的方法，但這種方式有乙個問題，就是判斷使用b1還是b2的，以及例項化每次都要這麼寫，一是比較麻煩，二是沒有收窄建立邏輯（如果建立邏輯發生變化，我們得到處改**），因此我們做乙個改進：
第2中方式(建立工廠)：
public class createbfactory
第2種方式，對於一般的情況應該是夠用了，但有的時候，建立邏輯比較簡單，或者是不想要這個建立邏輯，而是在程式配置檔案中直接指明用什麼，這就是第3種方式。
第3種方式（配置）：
這裡假設配置格式是：
一般的情況下，我們要建立乙個類例項，是必須知道類型別的，我們在**中無法直接用類名字串來建立例項的，但由於很多語言都支援根據元資料，並根據元資料動態建立例項，那麼我們當然就可以利用這種配置資訊來建立類例項。在c#中的**其實很簡單:
string thetypename = "完全類名,程式集名";//完全類名包括了命名空間的完整型別名，注意大小寫，程式集名則是要例項化類所在的程式集，如果在當前載入的程式集中，可以不寫。
type thetargettype = type.gettype(thetypename );
然後呼叫activtor.createinstancefrom(thetargettype )就可以動態構建。
如果我們的系統中存在著大量這樣的類需要建立，而且建立邏輯簡單，那麼採用這種方式有如下好處：
1）只要寫乙個根據配置檔案建立目標例項的工廠類，大大減少了**；
2）如果要將b1換到b2，我們只需要改配置檔案，而不需要修改程式，當然也就不需要重新編譯程式了
3）為按需引導程式集，動態引導程式集提供了可能。
第3種方式其實就是典型的ioc.至於配置資訊是放在資料庫還是檔案裡，存什麼格式都可以根據自己的需要來決定，甚至可以根據命名規範來進行（比如我的資料訪問類根據資料庫型別的不同分為不同的版本類，我就直接利用命名規範來實現配置,比如介面i_name,oracle版:c_name_o,因為程式集是肯定會載入的，我就可以根據i_name的型別名加上採用哪個資料庫的配置資訊就可以輕鬆建立需要的例項）。當然，根據配置檔案我們還可以完成很多更為複雜的事情，但原理是一樣的。
ioc：配置資訊+類的動態例項化技術。
不過這種技術並不適合建立邏輯複雜的地方，一是因為如果配置檔案過於複雜，本身也難以維護，二是配置檔案所能表達的邏輯也有限。ioc特別適合建立邏輯簡單，配置資訊形式統一，但量比較大的地方。
Spring系列 5 IOC技術
說實話，我對spring技術還是不算很了解，ioc的技術我在實體框架技術中提到過，但ioc和aop作為spring技術的兩個核心思想，我覺得在總結之前，還是有必要說明一下我所理解的ioc.我們知道，如果兩個事務之間存在邏輯關係，而且你需要根據這個邏輯關係做事，比如類a和類b，類a需要呼叫類b的方法，...
spring技術內幕5 IoC容器的依賴注入
1 當spring ioc容器完成了bean定義資源的定位 載入和解析註冊以後，ioc容器中已經管理類bean定義的相關資料，但是此時ioc容器還沒有對所管理的bean進行依賴注入，依賴注入在以下兩種情況發生 1 使用者第一次通過getbean方法向ioc容器索要bean時，ioc容器觸發依賴注入。...
5 IOC工廠模式
定位資源 resource resource new filesystemresource new file src main resources conf spring mybatis.xml beanfactory beanfactory new xmlbeanfactory resource ...