IoC框架最本質的東西：反射或者EMIT來例項化物件。然後我們可以加上快取，或者一些策略來控制物件的生命週期，比如是否是單例物件還是每次都生成一個新的物件。
DI實現其實很簡單，首先設計類來實現介面，而不是把所有的程式邏輯寫在一個類檔案中，然後我們傳入一個介面和一個繼承自介面的類作為引數，然後我們在相應的函式那將泛型引數T作為形參，虛擬碼:
//呼叫部分
HandleDI<ITest, Test>
//實現部分
HandleDI<TInterface, T>
// 使用反射，EMIT，委託來例項化T建立TInterface的物件
然後我們使用反射或者EMIT或是委託TInterface物件。這就是DI的實現過程。
DI說白了，作用就是例項化繼承自介面的類
之前對DI注入與控制器擴充套件竟然用依賴性解析器來實現，兩個方面深感疑惑，由於越學越不懂，越學越頭暈，因此就暫且放下了，接著學習，誰知道今天寫程式涉及到這些，就繼續研究了一下，哪知道，現在研究理解起來越來越順手，思路也清晰，於是趁熱打鐵，大概的理解了一遍，雖說學習是個遺忘的過程，至少自己理解過就好…
對於自己現在能夠很好地理解這塊知識，我覺得是這個原因：學習是個循序漸進的過程，可以一開始我們遇到問題，略作思考研究，實在不行暫且放下，繼續往下走，慢慢的等你學習的足夠了，有了一定的知識體系，當你在遇到這樣的問題時，你就能很好地解決它…
DI:依賴性注入是一種設計模式，用來實現程式塊之間的鬆散耦合
DI容器:本質上是一個智慧工廠，它為相互依賴的元件提供抽象，將依賴（低層模組）物件的獲得交給第三方（系統）來控制，即依賴物件不在被依賴模組的類中直接通過new來獲取，說白點就是建立物件的例項，並且例項化物件的依賴性。
控制器預設只能接受無參的建構函式，但，如果我們需要為其傳遞引數又該如何做呢？《利用MVC基本工具Ninject消除程式類之間的耦合的簡單示例》實現了(相關分析請看《MVC模式中的DI與DI容器理解》)。可是，有個疑問：為什麼要用到DI容器來做呢？甚至是依賴性解析器的方法來建立自定義控制器以實現控制器的重構(構造接收引數的控制器)？在我們一般的處理思路來看，應該是從其底層的實現模組來做，最基本的就是自定義控制器，可是為什麼可以使用依賴性解析器呢？
分析:
構造有引數的控制器，本質上是重構控制器，向原有的控制器中注入引數，這其實就是依賴性注入DI的一種：構造器注入。我們向控制器的建構函式中傳遞引數使其能夠接受引數:
public HomeController(IValueCalculator calcParam) { calc = calcParam; }
我們為控制器注入了我們的依賴性——IValueCalculator介面，但是，當我們除錯的時候，並不能夠呈現出頁面，相反會給我們報錯，這是因為我們單單就是傳入了引數而已，控制器的內部還是沒有進行半點處理。我們使用依賴性解析器來進行處理，依賴性解析器可以用於例項化控制器。依賴性解析器有兩個主要部件組成:
靜態的DependencyResolver類，他對解析依賴性扮演著靜態閘道器作用；
IDependencyResolver介面，該介面可以由知道如何解析依賴性的類來實現（通過使用DI容器），而且靜態的DependencyResolver將進入該實現進行呼叫，以執行其工作。
最後DI容器與依賴性解析器就會重構控制器以實現控制器的引數化。
可以得出結論:控制器的引數化可以用依賴性解析器來重構控制器，是因為控制器的引數化，是利用構造器來注入的，構造器注入是依賴性注入的一種形式。DI容器是需要依賴性(一般是介面)的類(這裡是控制器)和依賴性的具體實現(一般是介面的繼承類)之間的一個第三方元件.依賴性解析器與DI容器兩者相互依存
ASP.NET MVC的IOC注入有三種方式，也就是說我們有三種方式來重構控制器：
1.實現了IControllerFactory介面的DefaultControllerFactory；
2.實現了IDependencyResolver介面的DefaultDependencyResolver；
3.實現了IControllerActivator介面的DefaultControllerActivator；
最直接的就是自定義控制器工廠，在ASP.NET MVC 1.0時就是使用這種方法。具體的看《ASP.NET MVC使用自定義控制器工廠來實現IOC注入》
《MVC三個IOC注入點之Ninject使用示例》