首先說一下什麼是IOC和DIIOC是Inversion of Control（控制反轉）的簡寫DI是Dependency Injection（依賴注入）的簡寫martinfowler對IOC的解釋為Inversion of control is a common characteristic of frameworks so saying that these lightweight containers are special because they use inversion of control is like saying my car is special because it has wheels
我想對這一概念進行一個個人的闡述以方便我的理解控制反轉從字面意思來看就是控制權由被動變主動又變為被動或被動變主動又變為被動從這個角度來說IOC就變得非常容易理解了
舉個例子你的主管要求你做一件事情這個時候就存在這麼幾個過程
主管命令你做事情（這個時候主動權在主管你是被動的）
你接到命令做事情（這個時候主題是你你是主動的控制權在你手裡）
你完成事情（這個時候主題依然是你控制權在你手裡）
報告主管做完事情（主動權又叫交到主管手裡了）
上面的整個過程就完成了一次IOC從上面可以看出IOC的基本思想是控制權的轉換過程
舉個代碼的例子
假如有Class AClass B在A內部會初始化一個B調用B的一個方法DoMethod
public Class B
{
public void DoMethod（）
{
/// do somthing
}
}
public Class A
{
public void Excute（）
{
B b = new B（）
bDoMethod（）
}
}
假如在Main函數中如下執行
A a = new A（）
aExcute（）
從這兩行代碼來看事實上也存在一個IOC的過程a——>b——>a理解的關鍵點就在在A的內部調用Excute的時候方法bDoMethod的執行
理解了IOC我們再看一下DI從上面A調用B我們可以看出在初始化一個A的實例時也必須實例化一個B也就是說如果沒有B或者B出了問題A就無法實例化這就產生了一種依賴就是A依賴B這種依賴從設計的角度來說就是耦合顯然它是無法滿足高內聚低耦合的要求的這個時候就需要解耦當然解耦有很多種方法而DI就是其中一種不管任何一種解耦方法都不是說使A和B完全沒有關系而是把這種關系的實現變得隱晦不那麼直接但是又很容易實現而且易於擴展不像上面的代碼那樣直接new一個B出來那為什麼我們總是把IOC和DI聯系到一起呢？是因為DI的基本思想就是IOC而體現IOC 思想的方法還有另外一個那就是Service Locator這個方法好像涉及到的很少
DI依賴注入從字面意思就可以看出依賴是通過外接注入的方式來實現的這就實現了解耦而DI的方式通常有三種
構造器注入
屬性設置器注入
接口注入（我感覺接口注入是同時存在於上兩種注入方式的而不應該獨立出來）
以上的闡述只是為了先讓我們能對IOC和DI有一個感性的理解那麼IOC他真正解決的問題是什麼呢？我們講了那麼多主動被動的問題那我們是從什麼視角來看待這個問題的呢？所謂為什麼你是主動而我不是主動呢？這就需要一個參照物那這個參照物是什麼呢？就是容器在容器中來體現主動和被動用白話來講就是由容器控制程序之間的關系而非傳統實現中由程序代碼直接操控這也就是所謂控制反轉的概念所在控制權由應用代碼中轉到了外部容器控制權的轉移是所謂反轉這是通常對IOC的一個解釋從容器的角度來看主動和被動和由容器來控制程序之間的關系應該是相通的是一個意思到這裡我們就應該基本明白了IOC要解決的就是程序之間調用的一個問題它應該是一個思想層面的東西是一個中心就像一支樂隊的指揮而程序就是樂器通過指揮來協調各種樂器來演奏出美好的音樂來
From:http://tw.wingwit.com/Article/program/net/201311/13304.html
