正如咱們在《控制反轉》提到過的，不少人將IoC理解爲一種「面向對象的設計模式」，實際上IoC自身不只與面向對象沒有必然的聯繫，它也算不上是一種設計模式。通常來說，設計模式提供了一種解決某種具體問題的方案，可是IoC既沒有一個針對性的問題領域，其自身沒有提供一種可實施的解決方案，因此我更加傾向於將IoC視爲一種設計原則。實際上不少咱們熟悉的設計模式背後採用了IoC原則，接下來咱們就來介紹幾種典型的「設計模式」。html

1、模板方法

提到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)
    {
        <<省略實現>>
    }
}

2、工廠方法

對於一個複雜的流程來講，咱們傾向於將組成該流程的各個環節實如今相對獨立的組件之中，那麼針對流程的定製就能夠經過提供定製組件的方式來實現。咱們知道23種設計模式之中有一種重要的類型，那就是「建立型模式」，好比經常使用的「工廠方法」和「抽象工廠」，IoC所體現的針對流程的共享與定製能夠經過它們來完成。mvc

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

一樣以咱們的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方法中，咱們利用這些工廠方法提供的對象來具體完成請求處理流程的各個核心環節。async

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對象。ide

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();
}

3、抽象工廠

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

具體來講，咱們須要定義一個獨立的工廠接口或者抽象工廠類，並在其中定義多個的工廠方法來提供「同一系列」的多個相關對象。若是但願抽象工廠具備一組默認的「產出」，咱們也能夠將一個未被封閉的具體類做爲抽象工廠，以虛方法形式定義的工廠方法將默認的對象做爲返回值。咱們根據實際的須要經過實現工廠接口或者繼承抽象工廠類（不必定是抽象類）定義具體工廠類來提供一組定製的系列對象。

如今咱們採用抽象工廠模式來改造咱們的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框架[服務消費]

做者：蔣金楠
微信公衆帳號：大內老A
微博： www.weibo.com/artech 若是你想及時獲得我的撰寫文章以及著做的消息推送，或者想看看我的推薦的技術資料，能夠掃描左邊二維碼（或者長按識別二維碼）關注我的公衆號）。本文版權歸做者和博客園共有，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接，不然保留追究法律責任的權利。