之前的文章介紹了MVC如何通過ControllerFactory及ControllerActivator創建Controller，而Controller又是如何通過ControllerBase這個模板完成了功能的拓展及業務的執行。這一系列MVC類型的設計處處都體現了IoC的設計原則，所以本章將從以下幾點對ASP.NET MVC中的IoC進行介紹：
● 什么是IoC
● ASP.NET MVC中的IoC
● 什么是DI
● IoC容器與依賴解析器（Dependency Resolver）
● ASP.NET MVC中使用DI
什么是IoC
IoC（控制反轉，Inversion of Control）它是軟件開發中的一種設計原則，意思就是把控制權從自身(這里的自身大部分指代的是業務代碼)轉給其它對象來控制。IoC的意圖是將任務的執行從實現中解耦，可以專注於模塊任務的設計(如：操作數據庫的組件，可以有操作SQL Server和My SQL的)，系統本身不會關注這個模塊做了什么，同時當系統替換了這個模塊后不會對系統造成影響。在軟件開發中有幾種常見的基於IoC思想的實現：
● 工廠模式
● 模板模式
● 策略模式
● 依賴注入
以上模式都是將實現解耦，便於拓展。特別是依賴注入（DI，Dependency Injection），看到IoC更多想到的就依賴注入。
依賴倒置原則（DIP）：上面說了那么多的實現，但有一個根本的原則就是依賴倒置原則“高層模塊不依賴於低層模塊，它們都應該依賴於抽象，抽象不應該依賴於實現，實現應該依賴於抽象”。在.Net中就是使用接口和抽象類對業務和對象進行抽象，抽象與實現分開，如果放棄了這一原則實現依賴於實現，那么就反轉不了了(lll￢ω￢)。
ASP.NET MVC中的IoC
之前的文章中分析了ASP.NET MVC中Controller的創建過程和執行中主要的參與對象分別有：
● DefaultControllerFactory：工廠模式。
● DefaultControllerActivator：依賴注入(注：創建Controller時首先從依賴解析器中獲取Controller實例，無法獲取才自己創建)。
● ControllerBase：模板模式(注：ControllerBase定義了Execute模板方法調用抽象方法ExecuteCore，ExecuteCore的實現在子類中)。
這些對象的設計思想就是IoC。
什么是DI
DI（Dependency Injection，依賴注入），它其實是兩個部分，第一個是“依賴”，然后才是“注入”。
1. 依賴：簡單來說就是需要，在面向對象的一個類里面它“需要”其它類型來完成工作。如在MyBlog中的邏輯類需要倉儲類來操作數據庫，這種情況下就是邏輯類依賴倉儲類：
2. 注入：其實就是對類的依賴賦值，常用的注入的方式是：構造注入、屬性注入、方法注入，說白了就是通過構造方法、屬性(Setter方法)以及方法將依賴的對象傳入類的實例中並賦值。但要注意的是這個“注”字，為什么不直接用賦值？
舉個栗子：制作一個水球，要么留一個注水口，要么在制作的時候把水灌入然后封死。
對於有注水口的水球，在使用時如果注入紅色的水，就變成了紅色的水球，注入黃色的就是黃色的，而被封死的水球在制作時灌了什么顏色的水就是什么顏色的。
而在程序開發中更是如此，以MyBlog為例，業務邏輯類通過倉儲類來獲取數據，業務類可以“封死”只用SQL Server的操作類，也可以開放，在運行時將數據操作這個實例“注入”，那么注入SQL Server操作類就使用SQL Server，注入MySQL的就使用My SQL。
對水球注水首先要有水，其次是水球要有注水口，那么在程序里的“水”和“注水口”是什么？
IoC容器與依賴解析器（DependencyResolver）
在程序中所謂的“水”應該是那些抽象的實現，或者說實現了抽象的類型。比如操作SQL Server的倉儲類和操作MySQL的倉儲操作類。那么這些“水”要放在哪里？“水”當然要放在容器里，所以就有了IoC容器。
那IoC容器是什么？它可以簡單到只是一個實例的數組或字典，通過實例的類型（或實現的父類型、接口等）從這個字典或數組中獲取對應的實例，也可以是像Autofac、Ninject這些復雜成熟的IoC容器組件。
以下代碼分別是AutoFac和NinJect官方文檔中為容器注“水”的過程：
Ninject：https://github.com/ninject/ninject
AutoFac：https://autofac.org/
有了裝滿“水”的容器，想要把“水”注入到程序中，那就需要“注水口”依賴解析器（Denpendency Resolver）的支持。
以下代碼就是DefaultControllerActivator創建Controller的代碼：
想象一下，把上面的“注水口”連接到裝滿“水”的容器中，不是就能夠把需要的東西注入到需要的位置嗎？
ASP.NET MVC中使用DI
DI的使用有兩個必要條件就依賴容器和依賴解析器，ASP.NET中建議使用成熟的依賴容器，如Autofac等，它們提供了強大的功能並支持多種組件注冊到容器以及注入方式。而關於依賴解析器在ASP.NET MVC中是有默認解析器的，以下是ASP.NET MVC的解析器定義：
它實際的作用是通過Current屬性獲取一個IDependencyResolver的對象。
DependencyResolver中內置了一些實現該接口的對象，但是幾乎是無用的如下圖：
所以一般情況下如果在ASP.NET中都是實現IDependencyResolver接口然后通過DependencyResolver.SetResolver方法修改默認的依賴解析器。
在ASP.NET MVC中，使用依賴注入最頻繁的就是Controller，Controller作為業務邏輯執行的入口，它依賴業務邏輯的組件，而業務邏輯組件又依賴數據操作組件等等。所以在ASP.NET MVC中使用依賴注入實際上就是把Controller及其依賴都放入容器里，然后創建Controller時從容器中獲取即可。根據Controller的創建流程將使用方法分為以下幾種：
1. 實現IDependencyResolver接口然后通過DependencyResolver.SetResolver方法修改默認的依賴解析器(替換默認的“注水口”)。
2. 實現IControllerActivator接口，然后在創建DefaultControllerFactory時將其以參數的形式傳入到DefaultControllerFactory中(在ControllerActivator中添加自己的“注水口”，並替換掉原有的ControllerActivator)。
3. 繼承DefaultControllerFactory使用從容器中獲取Controller的方法將原有的GetControllerInstance方法替換掉（添加“注水口”放置在ControllerFactory中，放棄ControllerActivator的使用）。
注：由於在Controller類型中包含一個IDependencyResolver屬性，所以方法2和方法3沒有替換默認依賴解析器會導致Controller中使用該屬性無法訪問到真實的容器，如果需要在其基礎上使用方法1將默認的依賴解析器替換掉。
小結
IoC容器和依賴注入在軟件開發中是一個非常中要的概念，現在主流的一些開發框架的核心都是基於依賴注入的，即框架中的所有組件如日志、緩存、隊列等都會通過容器將其注入到使用的地方。本章主要以文字的形式介紹了IoC、DI的概念及其在ASP.NET MVC中的使用的三種方法，在下一篇文章中將會用代碼的形式介紹如何使用這三種方法在ASP.NET MVC中實現依賴注入。
參考：
https://en.wikipedia.org/wiki/Inversion_of_control