ASP.NET Core依賴注入系列教程之控制反轉（IoC）

這篇文章主要給大家介紹了關於ASP.NET Core依賴注入系列教程之控制反轉（IoC）的相關資料，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨着小編來一起學習學習吧

前言

ASP.NET Core在啓動以及後續針對每個請求的處理過程中的各個環節都需要相應的組件提供相應的服務，爲了方便對這些組件進行定製，ASP.NET通過定義接口的方式對它們進行了“標準化”，我們將這些標準化的組件稱爲服務，ASP.NET在內部專門維護了一個DI容器來提供所需的服務。要了解這個DI容器以及現實其中的服務提供機制，我們先得知道什麼是DI（Dependence Injection），而一旦我們提到DI，又不得不說IoC（Inverse of Control）。

一、流程控制的反轉

我聽到很多人將IoC說成是一種“面向對象的設計模式”，但在我個人看來IoC不能算作一種“設計模式”，其自身也與“面向對象”沒有直接的關係。很多人之所以不能很準確地理解IoC源於他們忽略了一個最根本的東西，那就是IoC這個短語。換句話說，很多人之所以對IoC產生了諸多誤解是因爲他們忽略了IoC的定義。

IoC的全名Inverse of Control，翻譯成中文就是“控制反轉”或者“控制倒置”。控制反轉也好，控制倒置也罷，它體現的意思是控制權的轉移，即原來控制權在A手中，現在需要B來接管。那麼具體對於軟件設計來說，IoC所謂的控制權的轉移具有怎樣的體現呢？要回答這個問題，就需要先了解IoC的C（Control）究竟指的是怎樣一種控制，在我看來這裏所謂的控制更多地體現爲一種“流程的控制”。

我們通過一個具體事例來說明傳統的設計在採用了IoC之後針對流程的控制是如何實現反轉的。比如說我們現在設計一個針對Web的MVC類庫，不妨將其命名爲MvcLib。MvcLib提供瞭如下所示的API幫助我們完成整個HTTP請求流程中的主要任務。具體來說，ListenAndReceiveRequest方法啓動一個監聽器綁定到指定的地址進行請求的監聽，接收到的請求通過一個Request對象返回。ActivateController方法根據接收到的請求解析並激活請求的目標Controller。ExecuteContrller方法執行激活的Controller並返回一個表示視圖的View對象。RenderView最終將View對象轉換成HTML並作爲當前請求響應的內容。

 public static class MvcLib
 {
 public static Request ListenAndReceiveRequest(Uri address);
 public static Controller ActivateController (Request request);
 public static View ExecuteContrller(Controller controller);
 public static void RenderView(View view);
 }

現在我們在這個MvcLib的基礎上創建一個真正的MVC應用，那麼除了按照MvcLib的規範自定義具體的Controller和View之外，我們還需要自行控制從請求的監聽與接收、Controller的激活與執行以及View的最終呈現在內的整個流程，這樣一個執行流程反映在如下所示的代碼中。

 public class App
 {
 static void Main(string[] args)
 {
 Uri address = new Uri("http://localhost/mvcapp");
 while (true)
 {
 Request request = MvcLib.ListenAndReceiveRequest(address);
 Task.Run(()=> ProcessRequest(request));
 }
 }
 
 private static void ProcessRequest(Request request)
 {
 Controller controller = MvcLib.ActiveController(request);
 View view = MvcLib.ExecuteContrller(controller);
 MvcLib.RenderView(view);
 }
 }

這個例子體現了右如圖所示的流程控制方式，即我們設計的類庫（MvcLib）僅僅通過API的形式提供某種單一功能的實現，作爲類庫消費者的應用程序（App）則需要自行編排整個工作流程。如果從重用的角度來講，這裏被重用的僅限於實現某個環節單一功能的代碼，編排整個工作流程的代碼並沒有得到重用。

當我們構建一個應用的時候，我們不僅僅是需要一個能夠提供API的類庫，實際上更理想的形式是直接在一個現有的框架上構架我們的應用。類庫（Library）和框架（Framework）的不同之處在於，前者往往只是提供實現某種單一功能的API，而後者則針對一個目標任務對這些單一功能進行編排形成一個完整的流程，這個流程在一個引擎的驅動下被執行。

在我們上面演示MvcLib來說，使用它的應用程序需要自行控制整個HTTP請求的處理流程，實際上這是一個很“泛化”的工作流程，幾乎所有的MVC應用均採用這樣的流程監聽、接收請求並最終對請求予以響應。如果我們將這個流程實現在一個MVC框架之中，由它構建的所有MVC應用就可以直接使用這個請求處理流程，而並不需要自行重複實現它。

現在我們將MvcLib從類庫改造成一個框架，並姑且將其稱爲MvcFrame。如左圖所示，MvcFrame的核心是一個被稱爲MvcEngine的執行引擎，它驅動一個編排好的工作流對HTTP請求進行一致性處理。如果我們利用MvcFrame構建一個具體的MVC應用，除了根據我們的業務需求定義相應的Controller和View之外，我們只需要初始化這個引擎並直接啓動它即可。如果你曾經開發過ASP.NET MVC應用，你會發現ASP.NET MVC就是這麼一個框架。

有了上面演示的這個例子作爲鋪墊，我們應該很容易理解IoC所謂的控制反轉了。總的來說，IoC是我們設計框架所採用的設計思想，所謂的控制反轉即是按照如右圖所示的方式將原來實現在應用程序流程控制轉移到框架中。被轉移的是一個泛化的可重用的處理流程，所以IoC符合軟件設計一個基本的原則，即重用性。

二、對流程的定製

我們採用IoC實現了流程控制從應用程序向框架自身的反轉，但是這個被反轉的僅僅是一個泛化的流程，任何一個具體的應用都可能需要對組成該流程的某些環節進行定製。如左圖所示，我們將一個泛化的工作流程（A=>B=>C）被定義在框架之中，建立在該框架的兩個應用需要對組成這個流程的某些環節進行定製。比如步驟A和C可以被App1重用，但是步驟B卻需要被定製（B1），App2則重用步驟A和B，但是需要按照自己的方式（C2）處理步驟C。

IoC將對流程的控制從應用程序轉移到框架之中，框架利用一個引擎驅動整個流程的執行。換句話說，應用程序無需關心該工作流程的細節，它只需要啓動這個引擎即可。但是這個引擎一旦被啓動，框架就會完全按照預先編排好的流程進行工作，如果應用程序希望整個流程按照自己希望的方式被執行，針對流程的定製一般在發生在啓動引擎之前。

一般來說，框架會以相應的形式提供一系列的擴展點，應用程序則通過定義擴展的方式實現對流程某個環節的定製。在引擎被啓動之前，應用程序將所需的擴展註冊到框架之中。一旦引擎被正常啓動，這些註冊的擴展會自動參與到整個流程的執行過程中。

雖然應用程序是框架引擎的啓動着，但是一旦引擎被啓動之後它就喪失了對流程的控制，應用程序對流程的定製不是在執行過程中對框架的干預來完成的，而只需要在流程執行之前就將定製的部分準備好，框架自身在執行過程中會智能地選擇它們。從這個意義上講，IoC對流程的定製遵循着這樣一個原則，即“Don't call us, we'll call you!”，它被稱爲好萊塢原則。

綜上所述，IoC一方面通過流程控制從應用程序向框架的反轉實現了針對流程自身的重用，另一方面採用“好萊塢原則”使得這個被重用的流程可能自由地被定製，這兩個因素實際上決定了框架自身的價值。重用讓框架不僅僅是爲應用程序提供實現單一功能的API，而是提供一整套可執行的解決方案；可定製則使我們可以爲不同的應用程序對框架進行定製，這無疑讓框架可以使用到更多的應用之中。

三、 IoC模式

正如我們在上面提到過的，很多人將IoC理解爲一種“面向對象的設計模式”，實際上IoC自身不僅與面向對象沒有必然的聯繫，它也算不上是一種設計模式。一般來講，設計模式提供了一種解決某種具體問題的方案，但是IoC既沒有一個針對性的問題領域，其自身沒有提供一種可實施的解決方案，所以我更加傾向於將IoC視爲一種設計原則，實際上很多我們熟悉的設計模式背後採用了IoC原則。

模板方法（Template Method）

提到IoC，很多人首先想到的是DI，但是在我看來與IoC聯繫得最爲緊密的則是另一種被稱爲“模板方法”的設計模式。模板方法模式與IoC的意圖可以說完全一致，該模式主張將一個可複用的工作流程或者由多個步驟組成的算法定義成模板方法，組成這個流程或者算法的步驟則實現在相應的虛方法之中，模板方法根據流程先後調用這些虛方法。所有這些方法均定義在同一個類中，我們可以通過派生該類並重寫相應的虛方法達到對流程定製的目的。

對於上面我們演示的這個MVC的例子，我們可以將整個請求處理流程實現在如下一個MvcEngine類中，請求的監聽與接收、目標Controller的激活與執行以及View的呈現則分別定義在四個受保護的虛方法中，模板方法Start根據預定義的請求處理流程先後調用這四個方法。

 public class MvcEngine
 {
 public void Start(Uri address)
 {
 while (true)
 {
 Request request = this.OnListenAndReceiveRequest(address);
 Task.Run(() =>
 {
  Controller controller = this.OnActivateController(request);
  View view = this.OnExecuteContrller(controller);
  this.OnRenderView(view);
 });
 }
 }
 protected virtual Request OnListenAndReceiveRequest(Uri address) ;
 protected virtual Controller OnActivateController(Request request) ;
 protected virtual View OnExecuteContrller(Controller controller) ; 
 protected virtual void OnRenderView(View view) ;
 }

對於具體的應用來說，如果定義在MvcEngine針對請求的處理方式完全符合它的要求，它只需要創建這個一個MvcEngine對象，然後指定一個對應的基地址調用模板方法Start開啓這個MVC引擎即可。如果該MVC引擎處理請求的某個環節不能滿足它的要求，它可以創建MvcEngine的派生類，並重寫實現該環節的相應虛方法即可。比如說定義在某個應用程序中的Controller都是無狀態的，它希望採用單例（Singleton）的方式重用已經激活的Controller以提高性能，那麼它就可以按照如下的方式創建一個自定義的FoobarMvcEngine並按照自己的方式重寫OnActivateController方法既可。

 public class FoobarMvcEngine : MvcEngine
 {
 protected override View OnExecuteContrller(Controller controller)
 {
 <<省略實現>>
 }
 }

模板方法如果結合“事件註冊”往往可以使應用程序對流程的定製變得更加自由。如下面的代碼片段所示，我們爲Controller的激活與執行以及View的呈現定義了六個事件，它們分別在這個三個環節開始之前和結束之後被觸發。這麼一個MvcEngine可以直接被使用，應用程序只需要註冊相應的事件完成對請求處理流程的定製。

 public class MvcEngine
 {
 //其他成員
 protected virtual Controller OnActivateController(Request request) ;
 protected virtual View OnExecuteContrller(Controller controller) ; 
 protected virtual void OnRenderView(View view) ;
 
 public EventHandler<ControllerActivationEventArgs> ControllerActivating;
 public EventHandler<ControllerActivationEventArgs> ControllerActivated;
 public EventHandler<ControllerExecutionEventArgs> ControllerExecuting;
 public EventHandler<ControllerExecutionEventArgs> ControllerExecuted;
 public EventHandler<ViewRenderEventArgs> ViewRendering;
 public EventHandler<ViewRenderEventArgs> ViewRendered;
 }

工廠方法（Factory Method）

對於一個複雜的流程來說，我們傾向於將組成該流程的各個環節實現在相應獨立的組件之中，那麼針對流程的定製就可以通過提供不同組件的形式來實現。我們知道23種設計模式之中有一種重要的類型，那就是“創建型模式”，比如常用的“工廠方法”和“抽象工廠”，那麼IoC所體現的針對流程的共享與定製可以通過它們來完成。

所謂的工廠方法，說白了就是在某個類中用於提供依賴對象的方法，這個方法可以是一個單純的虛方法，也可以是具有默認實現的虛方法，至於方法聲明的返回類型，可以是一個接口或者抽象類，也可以是未被封閉（Sealed）的具體類型。作爲它的派生類型，它可以實現或者重寫工廠方法以提供所需的具體對象。

同樣以我們的MVC框架爲例，我們讓獨立的對象來完成組成整個請求處理流程的四個核心環節。具體來說，我們分別定義了四個核心的類型（Listener、ControllerActivator、ControllerExecutor和ViewGenderer）來分別負責請求監聽與接收、Controller的激活、Controller的執行以及View的呈現。這四個對象按照如右圖所示的順序相互協作完成對請求的處理。

如下所示的Listener、ControllerActivator、ControllerExecutor和ViewGenderer這四個類型的簡單定義。我們沒有將它們定義成單純的抽象類或者接口，而是未被封閉可以被繼承的一般類型，定義其中的虛方法具有默認的實現。只有這些默認的實現方式無法滿足應用程序具體需求的時候，我們才需要定義相應的派生類。

 public class Listener
 {
 public virtual Request Listen(Uri address) ;
 }
 
 public class ControllerActivator
 {
 public virtual Controller ActivateController(Request request) ;
 }
 
 public class ControllerExecutor
 {
 public virtual View ExecuteController(Controller controller) ;
 }
 
 public class ViewRenderer
 {
 public virtual void RenderView(View view) ;
 }

在作爲MVC引擎的MvcEngine類中，我們定義了四個工廠方法（GetListener、GetControllerActivator、GetControllerExecutor和GetViewRenderer）來提供上述這四種類型的對象。這四個工廠方法均爲具有默認實現的虛方法，它們默認提供上述四種類型的對象。在用於啓動引擎的Start方法中，我們利用這些工廠方法提供的對象來具體完成請求處理流程的各個核心環節。

 public class MvcEngine
 {
 public void Start(Uri address)
 {
  while (true)
  {
  Request request = this.GetListener().Listen(address);
  Task.Run(() =>
  {
   Controller controller = this.GetControllerActivator()
   .ActivateController(request);
   View view = this.GetControllerExecutor()
   .ExecuteController(controller);
   this.GetViewRenderer().RenderView(view);
  });
  }
 }
 
 protected virtual Listener GetListener()
 {
  return new Listener();
 }
 
 protected virtual ControllerActivator GetControllerActivator()
 {
  return new ControllerActivator();
 }
 
 protected virtual ControllerExecutor GetControllerExecutor()
 {
  return new ControllerExecutor();
 }
 
 protected virtual ViewRenderer GetViewRenderer()
 {
  return new ViewRenderer();
 }
 }

對於具體的應用程序來說，如果需要對請求處理的某個環節進行定製，它需要將定製的操作實現在對應類型（Listener、ControllerActivator、ControllerExecutor和ViewGenderer）的派生類中。在MvcEngine的派生類中，我們需要重寫對應的工廠方法來提供被定製的對象。比如上面提及的以單例模式提供目標Controller對象的實現就定義在SingletonControllerActivator類中，我們在派生於MvcEngine的FoobarMvcEngine類中重寫了工廠方法GetControllerActivator使其返回一個SingletonControllerActivator對象。

 public class SingletonControllerActivator : ControllerActivator
 {
 public override Controller ActivateController(Request request)
 {
  <<省略實現>>
 }
 }
 
 public class FoobarMvcEngine : MvcEngine
 {
 protected override ControllerActivator GetControllerActivator()
 {
  return new SingletonControllerActivator();
 }
 }

上面我們採用工廠方法模式對MVC框架進行了重新設計，右圖清晰地展示了該框架以MvcEngine爲核心的相關組件之間的相互關係，同時也體現了採用派生MvcEngine（FoobarMvcEngine）具體的應用是如何通過重寫工廠方法（GetControllerActivator）對框架實施定製的。

抽象工廠（Abstract Factory）

雖然工廠方法和抽象工廠均提供了一個“生產”對象實例的工廠，但是兩者在設計上卻有本質的不同。工廠方法利用定義在某個類型的抽象方法或者虛方法實現了針對單一對象提供方式的抽象，而抽象工廠在利用一個獨立的接口或者類來實現對一組相關對象提供的抽象。

具體來說，我們需要定義一個獨立的工廠接口或者抽象工廠類，並在其中定義多個的工廠方法來提供“同一系列”的多個相關對象。如果希望抽象工廠具有一組默認的“產出”，我們也可以將一個未被封閉的具體類作爲抽象工廠，以虛方法形式定義的工廠方法將默認的對象作爲返回值。我們根據實際的需要通過實現工廠接口或者繼承抽象工廠類（不一定是抽象類）定義具體工廠類來提供一組定製的系列對象。

現在我們採用抽象工廠模式來改造我們的MVC框架。如下面的代碼片段所示，我們定義了一個實例類EngineFactory作爲創建MvcEngine所需四種對象（Listener、ControllerActivator、ControllerExecutor和ViewGenderer）的抽象工廠，定義其中的四個工廠方法的返回值體現了工廠默認的產出。我們在創建MvcEngine對象可以提供一個具體的EngineFactory對象（如果沒有顯式指定，MvcEngine默認使用的是一個自動創建的EngineFactory對象）。在用於啓動引擎的Start方法中，MvcEngine利用EngineFactory來獲取相應的對象協作完整對請求的處理流程。對於我們採用抽象工廠改造後的MVC框架，以MvcEngine爲核心的相關組件之間的關係體現在如左圖所示的UML中。

 public class EngineFactory
 {
 public virtual Listener GetListener()
 {
  return new Listener();
 }
 
 public virtual ControllerActivator GetControllerActivator()
 {
  return new ControllerActivator();
 }
 
 public virtual ControllerExecutor GetControllerExecutor()
 {
  return new ControllerExecutor();
 }
 
 public virtual ViewRenderer GetViewRenderer()
 {
  return new ViewRenderer();
 }
 }
 
 public class MvcEngine
 {
 public EngineFactory Factory { get; private set; }
 
 public MvcEngine(EngineFactory factory = null)
 {
  this.Factory = factory ?? new EngineFactory();
 }
 
 public void Start(Uri address)
 {
  while (true)
  {
  Request request = this.Factory.GetListener().Listen(address);
  Task.Run(() =>
  {
   Controller controller = this.Factory.GetControllerActivator()
   .ActivateController(request);
   View view = this.Factory.GetControllerExecutor()
   .ExecuteController(controller);
   this.Factory.GetViewRenderer().RenderView(view);
  });
  }
 }
 }

如果具體的應用程序需要採用上面定義的SingletonControllerActivator以單例的模式來激活目標Controller，我們可以按照如下的方式定義一個具體的工廠類FoobarEngineFactory。最終的應用程序將這麼一個FoobarEngineFactory對象作爲MvcEngine的EngineFactory。

 public class FoobarEngineFactory : EngineFactory
 {
 public override ControllerActivator GetControllerActivator()
 {
  return new SingletonControllerActivator();
 }
 }
 
 public class App
 {
 static void Main(string[] args)
 {
  Uri  address = new Uri("http://localhost/mvcapp");
  MvcEngine engine = new MvcEngine(new FoobarEngineFactory());
  Engine.Start(address);
 }
 }

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對神馬文庫的支持。

ASP.NET Core依賴注入系列教程之控制反轉（IoC）

SQL優化-20231016

爲HttpClient添加默認請求報頭的四種解決方案

ASP.NET Core依賴注入系列教程之控制反轉（IoC）

ASP.NET Core依賴注入系列教程之服務的註冊與提供

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結