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中的運用體現，可能兩個方面在印證上存在一些差異，但總體來說，最終的目的都是：是提高了框架的可用性且減輕應用程式的復雜性，
控制反轉的思想在框架上的運用體現不光局限在本義上（應用程式對流程控制權轉移到框架），其中很有很多細節，本文不在此一一闡述，例如這其中還有：在反轉后應用程式的代碼于框架直接采用“好萊塢法則”進行互動、框架的流程為應用程式開放環節的定制化等等，
總體而言，在一個基于控制反轉思想的框架上進行應用開發，就相當于在一條除錯好的流水線上生產某種產品，我們只需要在相應的環節準備對應的原材料，最終依賴于流水線的標準化、自動化的處理流程，我們就能得到相應的產品，
知識改變命運轉載請註明出處，本文鏈接：https://www.uj5u.com/net/500228.html
標籤：.NET技术