控制反轉IoC(Invers of Control)

1.反轉的體現

控制反轉，即IoC(Invers of Control)，它並不是屬於某個特定編程語言的技術，本質上它是設計框架的一種基本思想。ASP.NET Core中的依賴註入其實就是結合了控制反轉的思想所設計出的一套框架。所以為了更好掌握依賴註入，我們就必須先對控制反轉有一個初步的認識。控制反轉實際上是一種“控制權的轉移”的體現，下麵通過一個例子來看看它是怎麼體現“控制權的轉移”這回事的。

我們通常在日常生活中，用餐這件事是必不可少的，並且實際的用餐權掌握在我們自己手中，所以由我們自己決定什麼時候用餐，用餐時吃什麼食物。當有一天你生病了，於是你的父母因為要照料你，此時會由他們決定你每天什麼時間用餐，具體吃什麼。這個時候控制權(用餐權)就發生了轉移，控制權(用餐權)由你轉移到了你父母那裡了。

那麼我們在回到軟體設計當中來，控制反轉中的控制權實際上就是針對某個任務的流程式控制制，而“控制權的轉移”實際上就是將應用程式中對流程的控制轉移到框架中。在初步瞭解控制反轉控制的是什麼，以及反轉的雙方是誰後，其實從錶面上我們還是很難明白其中的含義，為什麼要實現控制反轉？不實現控制反轉會怎麼樣？

2.不實現控制反轉的例子

接下來我們通過一個實例來看看，如果應用程式中的某個流程不實現控制反轉，會對應用程式帶來什麼樣的問題。假設ASP.NET框架沒有為我們提供MVC處理HTTP請求的流程，只是提供了一個類庫並將處理流程的方法包含在名為MvcLib的類中。其中處理各個流程的方法如下代碼：

1 public  class MvcLib
2 {
3     public static void Listen(Url address);
4     public static Request Receive();
5     public static Controller CreateController(Request request);
6     public static View ExecuteController(Controller controller);
7     public static void RenderView(View view);
8 }

在這個例子中，由於ASP.NET框架沒有提供MVC處理HTTP請求的流程，所以我們不得不在應用程式中自行設計使用流程，基於MVC的思想我們將處理流程的處理設計如下圖：

在設計好MVC的流程後，我們使用框架提供的類庫方法，自行調用實現MVC處理HTTP請求的機制，代碼如下：

 1 while(true)
 2 {
 3     var address=new Uri("http://0.0.0.0:8080");
 4     MvcLib.ListenAsync(address);
 5     while(true)
 6     {
 7         var request=MvcLib.ReceiveAsync();
 8         var controller=MvcLib.CreateController(request);
 9         var view=MvcLib.ExecuteController(controller);
10         MvcLib.RenderView(view);
11     }
12 }

上面的示例就是一個框架沒有實現控制反轉的例子，導致流程的控制權在應用程式當中。這個例子中的ASP.NET框架，提供的MvcLib類僅僅是提供了各個流程環節的實現方法，ASP.NET框架沒有為我們制定MVC的流程實現，作為該類的消費者的應用程式，必須要自行編排MVC的工作流程，這無疑對應用程式本身來了一定程度的複雜性，如果流程的複雜程度高，編排流程出錯的風險也會隨之提高。

另外，對於MVC的處理流程通常是屬於比較典型的、廣泛化的需求。所以對於其他的ASP.NET應用程式也會使用到同樣的流程編排方式，那麼這就意味著編排整個MVC工作流程的代碼並沒有得到復用。

3.框架和類庫

在真實開發場景下，我們需要的不是一個僅僅能夠提供單一程式功能的類庫，而是能夠直接在上面構建應用的框架，所以為了讓框架不淪落成類庫，控制反轉是框架所採用的一種基本的設計思想、原則。

類庫和框架的不同之處在於，前者往往只是提供實現某種單一功能的API，而後者針對一個目標任務對這些單一功能進行編排，以形成一個完整的流程，並利用一個引擎驅動這個流程自動運轉。

類庫和框架的不同之處在於，類庫往往通過組件的形式為實現某個功能提供相應的API，而框架可以為某個常用的任務制定流程並對其環節進行編排，以便形成一個完整易用的流程提供給應用程式使用。

雖然如今框架和類庫是我們構建應用程式密不可分的東西，但是在傳統面向類庫編程的時代，大多數任務處理的流程都在應用程式放進行控制，在逐漸引入框架的開發方式後，任務處理的流程式控制制權才都被轉移到框架中。

4.ASP.NET Core中的控制反轉

上文對控制反轉的含義做了明確的解釋：即將一組流程的控制從應用程式中轉移到框架之中。個人覺得這個解釋比較偏巨集觀，更加偏向設計思想層面的一種解釋。而對於在ASP.NET Core中的控制反轉最直觀的一種解釋就是：將創建對象的控制權從應用程式轉移到了ASP.NET Core的依賴註入框架。

在ASP.NET Core中最直觀的一種感受就是：“從原來自己創建對象”，變成“自己不用創建對象，告訴別人需要什麼對象，別人主動提供對象”。如果在你沒有理解控制反轉和依賴註入這些概念，去接觸一個使用了依賴註入的項目，你把代碼翻個底朝天都找不到對象的實例在哪裡創建的，因為這創建對象這件事不在我們的應用程式中了，而是在ASP.NET Core的依賴註入框架（Dependency Injection）

解耦

ASP.NET Core借鑒控制反轉的思想設計出了依賴註入框架，帶給應用程式最大的一個好處就是“解耦”。

實際上我們開發的ASP.NET Core應用程式，本質上就是通過各個類的對象相互協作而構建的，某些複雜的功能也是通過調用各個類的對象，從而組成的流程體系，比如你點擊付款功能，這背後可能就有：訂單類、商品類、支付類等各個類協作實現功能。在這種背景下每個類都會直接或間接的產生依賴的關係，通過依賴註入可以實現一定程度的“解耦”，從而使應用程式能夠更好的適應需求的變化。

主動到被動

ASP.NET Core這種控制反轉的形式，比較類似於我們現在社會上企業的一種用人體制。通常企業都是主動發佈招聘信息，並且直接和員工簽署合同。隨著企業的長期經營，企業發現這種傳統的用人方式存在某些問題：1.崗位需求量大了後，如果每名員工都是企業直屬的，將會增加很大的開銷；2.某些崗位的流動性大，很會因為某些因素導致人員大量流失，會經常出現招聘不及時，無法填補工作空缺，或工作新舊交接出現問題。

“資本終歸是資本”，企業為了追求利益最大化，採取了一種新的用人制度，那就是我們通常說的“外包”，將員工的招聘交給第三方勞務公司，企業不在負責招聘只用專註業務和生產，上面的問題企業都不在擔心，第三方勞務公司會源源不斷的為企業主動提供員工。

這以社會現象其實就和我們ASP.NET Core這種控制反轉有著異曲同工之妙，只不過企業是在損人利己，而對框架而言是在追求更好的程式設計。

公司不在主動招聘員工，而是告知用人需求給第三方勞務公司後，由他們主動提供員工，這個現象就類似我們ASP.NET Core控制反轉的概念一樣，應用程式無需自己創建對象，只用將對象的需求告訴給框架，在使用時候框架將會主動提供。

5.結語

本文對Ioc控制反轉的概念從兩個方面進行瞭解釋，一種是基於框架思想層面，另一種是在ASP.NET Core中的運用體現。可能兩個方面在印證上存在一些差異，但總體來說，最終的目的都是：是提高了框架的可用性且減輕應用程式的複雜性。

控制反轉的思想在框架上的運用體現不光局限在本義上（應用程式對流程式控制制權轉移到框架），其中很有很多細節，本文不在此一一闡述，例如這其中還有：在反轉後應用程式的代碼於框架直接採用“好萊塢法則”進行交互、框架的流程為應用程式開放環節的定製化等等。

總體而言，在一個基於控制反轉思想的框架上進行應用開發，就相當於在一條調試好的流水線上生產某種產品。我們只需要在相應的環節準備對應的原材料，最終依賴於流水線的標準化、自動化的處理流程，我們就能得到相應的產品。