ASP.NET Core在啟動以及后續針對每個請求的處理過程中的各個環節都需要相應的組件提供相應的服務，為了方便對這些組件進行定制，ASP.NET通過定義接口的方式對它們進行了“標準化”，我們將這些標準化的組件稱為服務，ASP.NET在內部專門維護了一個DI容器來提供所需的服務。要了解這個DI容器以及現實其中的服務提供機制，我們先得知道什么是DI（Dependence Injection），而一旦我們提到DI，又不得不說IoC（Inverse of Control）。
目錄
一、流程控制的反轉
二、對流程的定制
三、 IoC模式
模板方法（Template Method）
工廠方法（Factory Method）
抽象工廠（Abstract Factory）
一、流程控制的反轉
我聽到很多人將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并作為當前請求響應的內容。
1: public static class MvcLib
2: {3: public static Request ListenAndReceiveRequest(Uri address);
4: public static Controller ActivateController (Request request);
5: public static View ExecuteContrller(Controller controller);
6: public static void RenderView(View view);
7: } 8: 現在我們在這個MvcLib的基礎上創建一個真正的MVC應用，那么除了按照MvcLib的規范自定義具體的Controller和View之外，我們還需要自行控制從請求的監聽與接收、Controller的激活與執行以及View的最終呈現在內的整個流程，這樣一個執行流程反映在如下所示的代碼中。
1: public class App
2: {3: static void Main(string[] args)
4: {5: Uri address = new Uri("http://localhost/mvcapp");
6: while (true)
7: { 8: Request request = MvcLib.ListenAndReceiveRequest(address); 9: Task.Run(()=> ProcessRequest(request)); 10: } 11: } 12: 13: private static void ProcessRequest(Request request)
14: { 15: Controller controller = MvcLib.ActiveController(request); 16: View view = MvcLib.ExecuteContrller(controller); 17: MvcLib.RenderView(view); 18: } 19: }這個例子體現了右如圖所示的流程控制方式，即我們設計的類庫（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根據預定義的請求處理流程先后調用這四個方法。
1: public class MvcEngine
2: {3: public void Start(Uri address)
4: {5: while (true)
6: {7: Request request = this.OnListenAndReceiveRequest(address);
8: Task.Run(() => 9: {10: Controller controller = this.OnActivateController(request);
11: View view = this.OnExecuteContrller(controller);
12: this.OnRenderView(view);
13: }); 14: } 15: }16: protected virtual Request OnListenAndReceiveRequest(Uri address) ;
17: protected virtual Controller OnActivateController(Request request) ;
18: protected virtual View OnExecuteContrller(Controller controller) ;
19: protected virtual void OnRenderView(View view) ;
20: }對于具體的應用來說，如果定義在MvcEngine針對請求的處理方式完全符合它的要求，它只需要創建這個一個MvcEngine對象，然后指定一個對應的基地址調用模板方法Start開啟這個MVC引擎即可。如果該MVC引擎處理請求的某個環節不能滿足它的要求，它可以創建MvcEngine的派生類，并重寫實現該環節的相應虛方法即可。比如說定義在某個應用程序中的Controller都是無狀態的，它希望采用單例（Singleton）的方式重用已經激活的Controller以提高性能，那么它就可以按照如下的方式創建一個自定義的FoobarMvcEngine并按照自己的方式重寫OnActivateController方法既可。
1: public class FoobarMvcEngine : MvcEngine
2: {3: protected override View OnExecuteContrller(Controller controller)
4: { 5: <<省略實現>> 6: } 7: }模板方法如果結合“事件注冊”往往可以使應用程序對流程的定制變得更加自由。如下面的代碼片段所示，我們為Controller的激活與執行以及View的呈現定義了六個事件，它們分別在這個三個環節開始之前和結束之后被觸發。這么一個MvcEngine可以直接被使用，應用程序只需要注冊相應的事件完成對請求處理流程的定制。
1: public class MvcEngine
2: {3: //其他成員
4: protected virtual Controller OnActivateController(Request request) ;
5: protected virtual View OnExecuteContrller(Controller controller) ;
6: protected virtual void OnRenderView(View view) ;
7: 8: public EventHandler<ControllerActivationEventArgs> ControllerActivating;
9: public EventHandler<ControllerActivationEventArgs> ControllerActivated;
10: public EventHandler<ControllerExecutionEventArgs> ControllerExecuting;
11: public EventHandler<ControllerExecutionEventArgs> ControllerExecuted;
12: public EventHandler<ViewRenderEventArgs> ViewRendering;
13: public EventHandler<ViewRenderEventArgs> ViewRendered;
14: }工廠方法（Factory Method）
對于一個復雜的流程來說，我們傾向于將組成該流程的各個環節實現在相應獨立的組件之中，那么針對流程的定制就可以通過提供不同組件的形式來實現。我們知道23種設計模式之中有一種重要的類型，那就是“創建型模式”，比如常用的“工廠方法”和“抽象工廠”，那么IoC所體現的針對流程的共享與定制可以通過它們來完成。
所謂的工廠方法，說白了就是在某個類中用于提供依賴對象的方法，這個方法可以是一個單純的虛方法，也可以是具有默認實現的虛方法，至于方法聲明的返回類型，可以是一個接口或者抽象類，也可以是未被封閉（Sealed）的具體類型。作為它的派生類型，它可以實現或者重寫工廠方法以提供所需的具體對象。
同樣以我們的MVC框架為例，我們讓獨立的對象來完成組成整個請求處理流程的四個核心環節。具體來說，我們分別定義了四個核心的類型（Listener、ControllerActivator、ControllerExecutor和ViewGenderer）來分別負責請求監聽與接收、Controller的激活、Controller的執行以及View的呈現。這四個對象按照如右圖所示的順序相互協作完成對請求的處理。
如下所示的Listener、ControllerActivator、ControllerExecutor和ViewGenderer這四個類型的簡單定義。我們沒有將它們定義成單純的抽象類或者接口，而是未被封閉可以被繼承的一般類型，定義其中的虛方法具有默認的實現。只有這些默認的實現方式無法滿足應用程序具體需求的時候，我們才需要定義相應的派生類。
1: public class Listener
2: {3: public virtual Request Listen(Uri address) ;
4: } 5: 6: public class ControllerActivator
7: {8: public virtual Controller ActivateController(Request request) ;
9: } 10: 11: public class ControllerExecutor
12: {13: public virtual View ExecuteController(Controller controller) ;
14: } 15: 16: public class ViewRenderer
17: {18: public virtual void RenderView(View view) ;
19: }在作為MVC引擎的MvcEngine類中，我們定義了四個工廠方法（GetListener、GetControllerActivator、GetControllerExecutor和GetViewRenderer）來提供上述這四種類型的對象。這四個工廠方法均為具有默認實現的虛方法，它們默認提供上述四種類型的對象。在用于啟動引擎的Start方法中，我們利用這些工廠方法提供的對象來具體完成請求處理流程的各個核心環節。
1: public class MvcEngine
2: {3: public void Start(Uri address)
4: {5: while (true)
6: {7: Request request = this.GetListener().Listen(address);
8: Task.Run(() => 9: {10: Controller controller = this.GetControllerActivator()
11: .ActivateController(request);12: View view = this.GetControllerExecutor()
13: .ExecuteController(controller);14: this.GetViewRenderer().RenderView(view);
15: }); 16: } 17: } 18: 19: protected virtual Listener GetListener()
20: {21: return new Listener();
22: } 23: 24: protected virtual ControllerActivator GetControllerActivator()
25: {26: return new ControllerActivator();
27: } 28: 29: protected virtual ControllerExecutor GetControllerExecutor()
30: {31: return new ControllerExecutor();
32: } 33: 34: protected virtual ViewRenderer GetViewRenderer()
35: {36: return new ViewRenderer();
37: } 38: }對于具體的應用程序來說，如果需要對請求處理的某個環節進行定制，它需要將定制的操作實現在對應類型（Listener、ControllerActivator、ControllerExecutor和ViewGenderer）的派生類中。在MvcEngine的派生類中，我們需要重寫對應的工廠方法來提供被定制的對象。 比如上面提及的以單例模式提供目標Controller對象的實現就定義在SingletonControllerActivator類中，我們在派生于MvcEngine的FoobarMvcEngine類中重寫了工廠方法GetControllerActivator使其返回一個SingletonControllerActivator對象。
1: public class SingletonControllerActivator : ControllerActivator
2: {3: public override Controller ActivateController(Request request)
4: { 5: <<省略實現>> 6: } 7: } 8: 9: public class FoobarMvcEngine : MvcEngine
10: {11: protected override ControllerActivator GetControllerActivator()
12: {13: return new SingletonControllerActivator();
14: } 15: }
上面我們采用工廠方法模式對MVC框架進行了重新設計，右圖清晰地展示了該框架以MvcEngine為核心的相關組件之間的相互關系，同時也體現了采用派生MvcEngine（FoobarMvcEngine）具體的應用是如何通過重寫工廠方法（GetControllerActivator）對框架實施定制的。
抽象工廠（Abstract Factory）
雖然工廠方法和抽象工廠均提供了一個“生產”對象實例的工廠，但是兩者在設計上卻有本質的不同。工廠方法利用定義在某個類型的抽象方法或者虛方法實現了針對單一對象提供方式的抽象，而抽象工廠在利用一個獨立的接口或者類來實現對一組相關對象提供的抽象。
具體來說，我們需要定義一個獨立的工廠接口或者抽象工廠類，并在其中定義多個的工廠方法來提供“同一系列”的多個相關對象。如果希望抽象工廠具有一組默認的“產出”，我們也可以將一個未被封閉的具體類作為抽象工廠，以虛方法形式定義的工廠方法將默認的對象作為返回值。我們根據實際的需要通過實現工廠接口或者繼承抽象工廠類（不一定是抽象類）定義具體工廠類來提供一組定制的系列對象。
現在我們采用抽象工廠模式來改造我們的MVC框架。如下面的代碼片段所示，我們定義了一個實例類EngineFactory作為創建MvcEngine所需四種對象（Listener、ControllerActivator、ControllerExecutor和ViewGenderer）的抽象工廠，定義其中的四個工廠方法的返回值體現了工廠默認的產出。我們在創建MvcEngine對象可以提供一個具體的EngineFactory對象（如果沒有顯式指定，MvcEngine默認使用的是一個自動創建的EngineFactory對象）。在用于啟動引擎的Start方法中，MvcEngine利用EngineFactory來獲取相應的對象協作完整對請求的處理流程。 對于我們采用抽象工廠改造后的MVC框架，以MvcEngine為核心的相關組件之間的關系體現在如左圖所示的UML中。
1: public class EngineFactory
2: {3: public virtual Listener GetListener()
4: {5: return new Listener();
6: } 7: 8: public virtual ControllerActivator GetControllerActivator()
9: {10: return new ControllerActivator();
11: } 12: 13: public virtual ControllerExecutor GetControllerExecutor()
14: {15: return new ControllerExecutor();
16: } 17: 18: public virtual ViewRenderer GetViewRenderer()
19: {20: return new ViewRenderer();
21: } 22: } 23: 24: public class MvcEngine
25: {26: public EngineFactory Factory { get; private set; }
27: 28: public MvcEngine(EngineFactory factory = null)
29: {30: this.Factory = factory ?? new EngineFactory();
31: } 32: 33: public void Start(Uri address)
34: {35: while (true)
36: {37: Request request = this.Factory.GetListener().Listen(address);
38: Task.Run(() => 39: {40: Controller controller = this.Factory.GetControllerActivator()
41: .ActivateController(request);42: View view = this.Factory.GetControllerExecutor()
43: .ExecuteController(controller);44: this.Factory.GetViewRenderer().RenderView(view);
45: }); 46: } 47: } 48: } 如果具體的應用程序需要采用上面定義的SingletonControllerActivator以單例的模式來激活目標Controller，我們可以按照如下的方式定義一個具體的工廠類FoobarEngineFactory。最終的應用程序將這么一個FoobarEngineFactory對象作為MvcEngine的EngineFactory。
1: public class FoobarEngineFactory : EngineFactory
2: {3: public override ControllerActivator GetControllerActivator()
4: {5: return new SingletonControllerActivator();
6: } 7: } 8: 9: public class App
10: {11: static void Main(string[] args)
12: {13: Uri address = new Uri("http://localhost/mvcapp");
14: MvcEngine engine = new MvcEngine(new FoobarEngineFactory());
15: Engine.Start(address); 16: } 17: }
ASP.NET Core中的依賴注入（1）：控制反轉（IoC）
ASP.NET Core中的依賴注入（2）：依賴注入（DI）
ASP.NET Core中的依賴注入（3）：服務注冊與提取
ASP.NET Core中的依賴注入（4）：構造函數的選擇與生命周期管理
ASP.NET Core中的依賴注入（5）：ServicePrvider實現揭秘【總體設計】
ASP.NET Core中的依賴注入（5）：ServicePrvider實現揭秘【解讀ServiceCallSite】
ASP.NET Core中的依賴注入（5）：ServicePrvider實現揭秘【補充漏掉的細節】
文章列表
留言列表
