依賴注入[2]: 基於IoC的設計模式

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

一、模板方法

提到IoC，很多人首先想到的是DI，但是在我看來與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並按照自己的方式重寫

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

二、工廠方法

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

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

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

  
  
  
          
 
           
public interface IWebLister
{
    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 IViewRender
{
    Task RendAsync(View view, HttpContext httpContext);
}
 
          

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

 
  
  
  
          
 
           
public class MvcEngine
{
    public async Task StartAsync(Uri address)
    {
        var listener = GetWebLister();
        var activator = GetControllerActivator();
        var executor = GetControllerExecutor();
        var render = 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 render.RendAsync(view, httpContext);
            }
            finally

            {
                await activator.ReleaseAsync(controller);
            }
        }
    }
    protected virtual IWebLister GetWebLister(); 
    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的接口作為抽象工廠，定義在其中定義了四個方法來提供請求監聽和處理過程使用到的4種核心對象。如果MVC提供了針對這四種核心組件的默認實現，我們可以按照如下的方式為這個抽象工廠提供一個默認實現（MvcEngineFactory）。

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

public class MvcEngineFactory： IMvcEngineFactory
{
    IWebLister GetWebLister();
    IControllerActivator GetControllerActivator();
    IControllerExecutor GetControllerExecutor();
    IViewRender GetViewRender();
}
 
          

現在我們采用抽象工廠模式來改造我們的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.GetWebLister();
        var activator = EngineFactory.GetControllerActivator();
        var executor = EngineFactory.GetControllerExecutor();
        var render = EngineFactory.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 render.RendAsync(view, httpContext);
            }
            finally
            {
                await activator.ReleaseAsync(controller);
            }
        }
    }
        
}
 
          

如果具體的應用程序需要采用上面定義的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://0.0.0.0:8080/mvcapp");
        MvcEngine engine     = new MvcEngine(new FoobarEngineFactory());
        engine.Start(address);
    }
}
 
          

除了上面介紹這三種典型的設計，還有很多其他的設計模式，比如策略模式、觀察者模式等等，它們無一不是采用IoC的設計原則。Martin Fowler在《Inversion of Control 》一文中正是通過觀察者模式來介紹IoC的。我們將在下一篇中對依賴注入模式進行深入講解。

依賴注入[1]: 控制反轉
依賴注入[2]: 基於IoC的設計模式
依賴注入[3]: 依賴注入模式
依賴注入[4]: 創建一個簡易版的DI框架[上篇]
依賴注入[5]: 創建一個簡易版的DI框架[下篇]
依賴注入[6]: .NET Core DI框架[編程體驗]
依賴注入[7]: .NET Core DI框架[服務注冊]
依賴注入[8]: .NET Core DI框架[服務消費]