[ASP.NET Core 3框架揭秘] 依賴注入[2]：IoC模式

正如我們在《依賴注入：控制反轉》提到過的，很多人將IoC理解為一種“面向對象的設計模式”，實際上IoC不僅與面向對象沒有必然的聯系，它自身甚至算不上是一種設計模式。一般來講，設計模式提供了一種解決某種具體問題的方案，但是IoC既沒有一個針對性的問題領域，其自身也沒有提供一種可操作性的解決方案，所以我們更加傾向於將IoC視為一種設計原則。很多我們熟悉的設計模式背后都采用了IoC原則，接下來我們就來介紹幾種典型的“設計模式”。

一、模板方法

提到IoC，很多人首先想到的是依賴注入，但是在我看來與IoC聯系得最為緊密的倒是另一種被稱為“模板方法（Template Method）”的設計模式。模板方法模式與IoC的意圖可以說不謀而合，該模式主張將一個可復用的工作流程或者由多個步驟組成的算法定義成模板方法，組成這個流程或者算法的單一步驟則實現在相應的虛方法之中，模板方法根據預先編排的流程去調用這些虛方法。這些方法均定義在一個類中，我們可以通過派生該類並重寫相應的虛方法的方式達到對流程定制的目的。

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

public class MvcEngine
{
    public async Task StartAsync(Uri address)
    {
        await ListenAsync(address);
        while (true)
        {
            var request = await ReceiveAsync();
            var controller = await CreateControllerAsync(request);
            var view = await ExecuteControllerAsync(controller);
            await RenderViewAsync(view);
        }
    }
    protected virtual Task ListenAsync(Uri address);
    protected virtual Task<Request> ReceiveAsync();
    protected virtual Task<Controller> CreateControllerAsync(Request request);
    protected virtual Task<View> ExecuteControllerAsync(Controller controller);
    protected virtual Task RenderViewAsync(View view);
}

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

public class FoobarMvcEngine : MvcEngine
{
    protected override Task<View> CreateControllerAsync (Request request)
    {
        <<省略實現>>
    }
}

二、工廠方法

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

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

同樣以我們的MVC框架為例，我們讓獨立的組件來完成整個請求處理流程的幾個核心環節。具體來說，我們為這些核心組件定義了如下幾個對應的接口。IWebListener接口用來監聽、接收和響應請求（針對請求的響應由ReceiveAsync方法返回的HttpContext上下文來完成），IControllerActivator接口用於根據當前HttpContext上下文激活目標Controller對象，並在Controller對象執行后做一些釋放回收工作。至於IControllerExecutor和IViewRender接口則分別用來完成針對Controller的執行和針對View的呈現。

public interface IWebListener
{
    Task ListenAsync(Uri address);
    Task<HttpContext> ReceiveAsync();
}

public interface IControllerActivator
{
    Task<Controller> CreateControllerAsync(HttpContext httpContext);
    Task ReleaseAsync(Controller controller);
}

public interface IControllerExecutor
{
    Task<View> ExecuteAsync(Controller controller, HttpContext httpContext);
}

public interface IViewRenderer
{
    Task RenderAsync(View view, HttpContext httpContext);
}

我們在作為MVC引擎的MvcEngine中定義了四個工廠方法（GetWebListener、GetControllerActivator、GetControllerExecutor和GetViewRenderer）來提供上述這四種組件。這四個工廠方法均為具有默認實現的虛方法，我們可以利用它們提供默認的組件。在用於啟動引擎的StartAsync方法中，我們利用這些工廠方法提供的對象來具體完成整個請求處理流程。

public class MvcEngine
{
    public async Task StartAsync(Uri address)
    {
        var listener = GetWebListener();
        var activator = GetControllerActivator();
        var executor = GetControllerExecutor();
        var renderer = GetViewRender();

        await listener.ListenAsync(address);
        while (true)
        {
            var httpContext = await listener.ReceiveAsync();
            var controller = await activator.CreateControllerAsync(httpContext);
            try
            {
                var view = await executor.ExecuteAsync(controller, httpContext);
                await renderer.RendAsync(view, httpContext);
            }
            finally
            {
                await activator.ReleaseAsync(controller);
            }
        }
    }
    protected virtual IWebLister GetWebListener(); 
    protected virtual IControllerActivator GetControllerActivator();
    protected virtual IControllerExecutor GetControllerExecutor();
    protected virtual IViewRender GetViewRender();
}

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

public class SingletonControllerActivator : IControllerActivator
{         
    public Task<Controller> CreateControllerAsync(HttpContext httpContext)
    {
        <<省略實現>>
    }
    public Task ReleaseAsync(Controller controller) => Task.CompletedTask;
}

public class FoobarMvcEngine : MvcEngine
{
    protected override ControllerActivator GetControllerActivator() => new SingletonControllerActivator();
}

三、抽象工廠

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

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

現在我們采用抽象工廠模式來改造我們的MVC框架。如下面的代碼片段所示，我們定義了一個名為IMvcEngineFactory的接口作為抽象工廠，並在其中定義了四個方法來提供請求監聽和處理過程使用到的四種核心對象。如果MVC提供了針對這四種核心組件的默認實現，我們可以按照如下的方式為這個抽象工廠提供一個默認實現（MvcEngineFactory）。

public interface IMvcEngineFactory
{
    IWebLister GetWebListener();
    IControllerActivator GetControllerActivator();
    IControllerExecutor GetControllerExecutor();
    IViewRender GetViewRender();
}

public class MvcEngineFactory： IMvcEngineFactory
{
    public virtual IWebListener GetWebListener();
    public virtual IControllerActivator GetControllerActivator();
    public virtual IControllerExecutor GetControllerExecutor();
    public virtual IViewRenderer GetViewRenderer();
}

現在我們采用抽象工廠模式來改造我們的MVC框架。我們在創建MvcEngine對象的時候提供一個具體的IMvcEngineFactory對象，如果沒有顯式指定，MvcEngine會默認使用EngineFactory對象。在用於啟動引擎的StartAsync方法中，MvcEngine利用IMvcEngineFactory對象來獲取相應的對象來完成對請求的處理流程。

public class MvcEngine
{
    public IMvcEngineFactory EngineFactory { get; }
    public MvcEngine(IMvcEngineFactory engineFactory = null)  => EngineFactory = engineFactory ?? new MvcEngineFactory();
        
    public async Task StartAsync(Uri address)
    {
        var listener = EngineFactory.GetWebListener();
        var activator = EngineFactory.GetControllerActivator();
        var executor = EngineFactory.GetControllerExecutor();
        var renderer= EngineFactory.GetViewRenderer();

        await listener.ListenAsync(address);
        while (true)
        {
            var httpContext = await listener.ReceiveAsync();
            var controller = await activator.CreateControllerAsync(httpContext);
            try
            {
                var view = await executor.ExecuteAsync(controller, httpContext);
                await render.RendAsync(view, httpContext);
            }
            finally
            {
                await activator.ReleaseAsync(controller);
            }
        }
    }        
}

如果具體的應用程序需要采用前面定義的SingletonControllerActivator以單例的模式來激活目標Controller對對象，可以按照如下的方式定義一個具體的工廠類FoobarEngineFactory。最終的應用程序將利用這個FoobarEngineFactory對象來創建作為引擎的MvcEngine對象即可。

public class FoobarEngineFactory : EngineFactory
{
    public override ControllerActivator GetControllerActivator()
    {
        return new SingletonControllerActivator();
    }
}

public class App
{
    static async Task Main()
    {
        var address = new Uri("http://0.0.0.0:8080/mvcapp");
        var engine = new MvcEngine(new FoobarEngineFactory());
        await engine.StartAsync(address);
        ...
    }
}

[ASP.NET Core 3框架揭秘] 依賴注入[1]：控制反轉
[ASP.NET Core 3框架揭秘] 依賴注入[2]：IoC模式
[ASP.NET Core 3框架揭秘] 依賴注入[3]：依賴注入模式
[ASP.NET Core 3框架揭秘] 依賴注入[4]：一個迷你版DI框架
[ASP.NET Core 3框架揭秘] 依賴注入[5]：利用容器提供服務
[ASP.NET Core 3框架揭秘] 依賴注入[6]：服務注冊
[ASP.NET Core 3框架揭秘] 依賴注入[7]：服務消費
[ASP.NET Core 3框架揭秘] 依賴注入[8]：服務實例的生命周期
[ASP.NET Core 3框架揭秘] 依賴注入[9]：實現概述
[ASP.NET Core 3框架揭秘] 依賴注入[10]：與第三方依賴注入框架的適配