正如咱們在《依賴注入:控制反轉》提到過的,不少人將IoC理解爲一種「面向對象的設計模式」,實際上IoC不只與面向對象沒有必然的聯繫,它自身甚至算不上是一種設計模式。通常來說,設計模式提供了一種解決某種具體問題的方案,可是IoC既沒有一個針對性的問題領域,其自身也沒有提供一種可操做性的解決方案,因此咱們更加傾向於將IoC視爲一種設計原則。不少咱們熟悉的設計模式背後都採用了IoC原則,接下來咱們就來介紹幾種典型的「設計模式」。html
提到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方法便可。mvc
public class FoobarMvcEngine : MvcEngine { protected override Task<View> CreateControllerAsync (Request request) { <<省略實現>> } }
對於一個複雜的流程來講,咱們傾向於將組成該流程的各個環節實如今相應的組件之中,那麼針對流程的定製就能夠經過提供相應組件的形式來實現。咱們知道23種設計模式之中有一種重要的類型,那就是「建立型模式」,好比經常使用的「工廠方法」和「抽象工廠」,IoC所體現的針對流程的共享與定製一樣能夠經過這些設計模式來完成。app
所謂的工廠方法,說白了就是在某個類中定義用來提供所需服務對象的方法,這個方法能夠是一個單純的虛方法,也能夠是具備默認實現的虛方法。至於方法聲明的返回類型,能夠是一個接口或者抽象類,也能夠是未封閉(Sealed)的具體類型。做爲它的派生類型,能夠實現或者重寫工廠方法以提供所需的服務對象。框架
一樣以咱們的MVC框架爲例,咱們讓獨立的組件來完成整個請求處理流程的幾個核心環節。具體來講,咱們爲這些核心組件定義了以下幾個對應的接口。IWebListener接口用來監聽、接收和響應請求(針對請求的響應由ReceiveAsync方法返回的HttpContext上下文來完成),IControllerActivator接口用於根據當前HttpContext上下文激活目標Controller對象,並在Controller對象執行後作一些釋放回收工做。至於IControllerExecutor和IViewRender接口則分別用來完成針對Controller的執行和針對View的呈現。async
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 IViewRender { Task RendAsync(View view, HttpContext httpContext); }
咱們在做爲MVC引擎的MvcEngine中定義了四個工廠方法(GetWebListener、GetControllerActivator、GetControllerExecutor和GetViewRenderer)來提供上述這四種組件。這四個工廠方法均爲具備默認實現的虛方法,咱們能夠利用它們提供默認的組件。在用於啓動引擎的StartAsync方法中,咱們利用這些工廠方法提供的對象來具體完成整個請求處理流程。ide
public class MvcEngine { public async Task StartAsync(Uri address) { var listener = GetWebListener(); 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 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(); }
雖然工廠方法和抽象工廠均提供了一個「生產」對象實例的工廠,可是二者在設計上卻有本質的不一樣。工廠方法利用定義在某個類型的抽象方法或者虛方法完成了針對「單一對象」的提供,而抽象工廠則利用一個獨立的接口或者抽象類來提供「一組相關的對象」。this
具體來講,咱們須要定義一個獨立的工廠接口或者抽象工廠類,並在其中定義多個工廠方法來提供「同一系列」的多個相關對象。若是但願抽象工廠具備一組默認的「產出」,咱們也能夠將一個未被封閉類型做爲抽象工廠,以虛方法形式定義的工廠方法將默認的對象做爲返回值。在具體的應用開發中,咱們能夠經過實現工廠接口或者繼承抽象工廠類(不必定是抽象類)的方式來定義具體工廠類,並利用它來提供一組定製的對象系列。
如今咱們採用抽象工廠模式來改造咱們的MVC框架。以下面的代碼片斷所示,咱們定義了一個名爲IMvcEngineFactory的接口做爲抽象工廠,並在其中定義了四個方法來提供請求監聽和處理過程使用到的四種核心對象。若是MVC提供了針對這四種核心組件的默認實現,咱們能夠按照以下的方式爲這個抽象工廠提供一個默認實現(MvcEngineFactory)。
public interface IMvcEngineFactory { IWebLister GetWebListener(); IControllerActivator GetControllerActivator(); IControllerExecutor GetControllerExecutor(); IViewRender GetViewRender(); } public class MvcEngineFactory: IMvcEngineFactory { public virtual IWebLister GetWebListener(); public virtual IControllerActivator GetControllerActivator(); public virtual IControllerExecutor GetControllerExecutor(); public virtual 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.GetWebListener(); 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對象便可。
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框架揭祕] 依賴注入:控制反轉
[ASP.NET Core 3框架揭祕] 依賴注入:IoC模式
[ASP.NET Core 3框架揭祕] 依賴注入:依賴注入模式
[ASP.NET Core 3框架揭祕] 依賴注入:一個迷你版DI框架