首先說一下什麼是IOC和DI，IOC是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 A，Class B，在A內部會初始化一個B，調用B的一個方法DoMethod
public Class B
{
public void DoMethod（）
{
/// do somthing；
}
}
public Class A
{
public void Excute（）
{
B b = new B（）；
b.DoMethod（）；
}
}
假如在Main函數中如下執行：
A a = new A（）；
a.Excute（）；
從這兩行代碼來看，事實上也存在一個IOC的過程，a——>b——>a，理解的關鍵點就在在A的內 部調用Excute的時候，方法b.DoMethod的執行。
理解了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要解決的就是程序之間調用的一個問題，它應該是一個思 想層面的東西，是一個中心，就像一支樂隊的指揮，而程序就是樂器，通過指揮來協調各種樂器，來演奏 出美好的音樂來。
