IoC框架最本質的東西：反射或者EMIT來實例化對象。然後我們可以加上緩存，或者一些策略來控制對象的生命周期，比如是否是單例對象還是每次都生成一個新的對象。 之前對DI註入與控制器擴展竟然用依賴性解析器來實現，兩個方面深感疑惑，由於越學越不懂，越學越頭暈，因此就暫且放下了，接著學習，誰知道今天寫程式 ...
IoC框架最本質的東西：反射或者EMIT來實例化對象。然後我們可以加上緩存，或者一些策略來控制對象的生命周期，比如是否是單例對象還是每次都生成一個新的對象。
之前對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使用示例》
