如何采用IoC實(shí)現(xiàn)對(duì)應(yīng)用程序的流程控制

我之前寫(xiě)過(guò)一系列關(guān)于.NET Core依賴(lài)注入的文章，由于.NET Core依賴(lài)注入框架的實(shí)現(xiàn)原理發(fā)生了很大的改變，加上我對(duì)包括IoC和DI這些理論層面的東西又有了一些新的理解。

軟件設(shè)計(jì)中由一些所謂的理念都沒(méi)有一個(gè)明確的定義，比如之前流行的SOA和現(xiàn)在炒的火熱的微服務(wù)（Micro Service）和無(wú)服務(wù)器（Serverless），我們都不能通過(guò)一個(gè)明確的“內(nèi)涵”給它們一個(gè)準(zhǔn)確地定義，只能從“外延”上描述這些架構(gòu)設(shè)計(jì)應(yīng)該具有怎樣的特性。正因?yàn)闊o(wú)法給出一個(gè)明確的界定，造成了人們針對(duì)同一個(gè)概念出現(xiàn)了很多不同的理解。針對(duì)IoC也是這種情況，所以本章所訴的僅僅代表作者的一家之言，讀者朋友姑妄聽(tīng)之，僅作參考。

一、流程控制的反轉(zhuǎn)

我聽(tīng)到很多人將IoC說(shuō)成是一種“面向?qū)ο蟮脑O(shè)計(jì)模式”，但在我個(gè)人看來(lái)IoC不能算作 一種“設(shè)計(jì)模式”，其自身也與“面向?qū)ο蟆睕](méi)有直接的關(guān)系。我覺(jué)得很多人之所以不能很準(zhǔn)確地理解IoC源于他們忽略了一個(gè)最根本的東西，那就是IoC這個(gè)短語(yǔ)，也就是他們之所以對(duì)IoC產(chǎn)生了諸多誤解是因?yàn)樗麄兒雎粤薎oC的定義。

IoC的全名Inverse of Control，翻譯成中文就是“控制反轉(zhuǎn)”或者“控制倒置”?？刂品崔D(zhuǎn)也好，控制倒置也罷，它體現(xiàn)的意思是控制權(quán)的轉(zhuǎn)移，即原來(lái)控制權(quán)在A手中，現(xiàn)在需要B來(lái)接管。那么具體對(duì)于軟件設(shè)計(jì)來(lái)說(shuō)，IoC所謂的控制權(quán)的轉(zhuǎn)移具有怎樣的體現(xiàn)呢？要回答這個(gè)問(wèn)題，就需要先了解IoC的C（Control）究竟指的是怎樣一種控制。對(duì)于我們所在的任何一件事，不論其大小，其實(shí)可以分解成相應(yīng)的步驟，所以任何一件事都有其固有的流程，IoC涉及的所謂控制可以理解為“針對(duì)流程的控制”。

我們通過(guò)一個(gè)具體事例來(lái)說(shuō)明傳統(tǒng)的設(shè)計(jì)在采用了IoC之后針對(duì)流程的控制是如何實(shí)現(xiàn)反轉(zhuǎn)的。比如說(shuō)現(xiàn)在設(shè)計(jì)一個(gè)針對(duì)Web的MVC類(lèi)庫(kù)，我們不妨將其命名為MvcLib。簡(jiǎn)單起見(jiàn)，這個(gè)類(lèi)庫(kù)中只包含如下這個(gè)同名的靜態(tài)類(lèi)。

public static class MvcLib

{
    public static Task ListenAsync(Uri address);
    public static Task ReceiveAsync();
    public static Task CreateControllerAsync(Request request);
    public static Task ExecuteControllerAsync(Controller controller);
    public static Task RenderViewAsync(View view);
}

MvcLib提供了如上5個(gè)方法幫助我們完成整個(gè)HTTP請(qǐng)求流程中的5個(gè)核心任務(wù)。具體來(lái)說(shuō)，ListenAsync方法啟動(dòng)一個(gè)監(jiān)聽(tīng)器并將其綁定到指定的地址進(jìn)行HTTP請(qǐng)求的監(jiān)聽(tīng)，抵達(dá)的請(qǐng)求通過(guò)ReceiveAsync方法進(jìn)行接收，我們將接收到的請(qǐng)求通過(guò)一個(gè)Request對(duì)象來(lái)表示。CreateControllerAsync方法根據(jù)接收到的請(qǐng)求解析并激活請(qǐng)求的目標(biāo)Controller對(duì)象。ExecuteControllerAsync方法執(zhí)行激活的Controller并返回一個(gè)表示視圖的View對(duì)象。RenderViewAsync最終將View對(duì)象轉(zhuǎn)換成HTML并作為當(dāng)前請(qǐng)求響應(yīng)的內(nèi)容返回給請(qǐng)求的客戶(hù)端。

現(xiàn)在我們?cè)谶@個(gè)MvcLib的基礎(chǔ)上創(chuàng)建一個(gè)真正的MVC應(yīng)用，那么除了按照MvcLib的規(guī)范自定義具體的Controller和View之外，我們還需要自行控制從請(qǐng)求的監(jiān)聽(tīng)與接收、Controller的激活與執(zhí)行以及View的最終呈現(xiàn)在內(nèi)的整個(gè)流程，這樣一個(gè)執(zhí)行流程反映在如下所示的代碼中。

class Program

{
    static async Task Main()
    {
         Uri address = new Uri("http://0.0.0.0:8080/mvcapp");
         await MvcLib.ListenAsync(address);
         while (true)
        {
            var request = await MvcLib.ReceiveAsync();
            var controller = await MvcLib.CreateControllerAsync(request);
            var view = await MvcLib.ExecuteControllerAsync(controller);
            await MvcLib.RenderViewAsync(view);
        }
    }    
}

這個(gè)例子體現(xiàn)了如圖1所示的流程控制方式（應(yīng)用的代碼完全采用異步的方式來(lái)處理請(qǐng)求，為了讓流程圖顯得更加簡(jiǎn)單，我們?cè)诹鞒虉D中畫(huà)成了同步的形式，讀者不必糾結(jié)這個(gè)問(wèn)題）。我們?cè)O(shè)計(jì)的類(lèi)庫(kù)（MvcLib）僅僅通過(guò)API的形式提供某種單一功能的實(shí)現(xiàn)，作為類(lèi)庫(kù)消費(fèi)者的應(yīng)用程序（App）則需要自行編排整個(gè)工作流程。如果從重用的角度來(lái)講，這里被重用的僅限于實(shí)現(xiàn)某個(gè)環(huán)節(jié)單一功能的代碼，編排整個(gè)工作流程的代碼并沒(méi)有得到重用。

圖1 流程控制掌握在應(yīng)用程序手中

但是當(dāng)我們構(gòu)建一個(gè)應(yīng)用的時(shí)候，我們需要的不僅僅是一個(gè)能夠提供單一API的類(lèi)庫(kù)，我們希望的理想形式是能夠直接在一個(gè)現(xiàn)有的框架上構(gòu)建我們的應(yīng)用。類(lèi)庫(kù)（Library）和框架（Framework）的不同之處在于，前者往往只是提供實(shí)現(xiàn)某種單一功能的API，而后者則針對(duì)一個(gè)目標(biāo)任務(wù)對(duì)這些單一功能進(jìn)行編排形成一個(gè)完整的流程，這個(gè)流程在一個(gè)引擎的驅(qū)動(dòng)下自動(dòng)執(zhí)行。

對(duì)于我們上面演示MvcLib來(lái)說(shuō)，作為消費(fèi)者的應(yīng)用程序需要自行控制整個(gè)HTTP請(qǐng)求的處理流程，但這是實(shí)際上這是一個(gè)很“泛化”的工作流程，幾乎所有的MVC應(yīng)用均采用這樣的流程監(jiān)聽(tīng)、接收請(qǐng)求并最終對(duì)請(qǐng)求予以響應(yīng)。如果我們將這個(gè)流程實(shí)現(xiàn)在一個(gè)MVC框架之中，由它構(gòu)建的所有MVC應(yīng)用就可以直接使用這個(gè)請(qǐng)求處理流程，而不需要自行重復(fù)實(shí)現(xiàn)它。

現(xiàn)在我們將MvcLib從類(lèi)庫(kù)改造成一個(gè)框架，并姑且將其稱(chēng)為MvcFrame。如圖2所示，MvcFrame的核心是一個(gè)被稱(chēng)為MvcEngine的執(zhí)行引擎，它驅(qū)動(dòng)一個(gè)編排好的工作流對(duì)HTTP請(qǐng)求進(jìn)行一致性處理。如果我們利用MvcFrame構(gòu)建一個(gè)具體的MVC應(yīng)用，除了根據(jù)我們的業(yè)務(wù)需求定義相應(yīng)的Controller和View之外，我們只需要初始化這個(gè)引擎并直接啟動(dòng)它即可。如果你曾經(jīng)開(kāi)發(fā)過(guò)ASP.NET MVC應(yīng)用，你會(huì)發(fā)現(xiàn)ASP.NET MVC就是這么一個(gè)框架。

圖2 流程控制反轉(zhuǎn)到框架手中

有了上面演示的這個(gè)例子作為鋪墊，我們應(yīng)該很容易理解IoC所謂的控制反轉(zhuǎn)。總的來(lái)說(shuō)，IoC是我們?cè)O(shè)計(jì)框架所采用的一種基本思想，所謂的控制反轉(zhuǎn)就是將對(duì)應(yīng)用流程的控制轉(zhuǎn)移到框架中。拿上面這個(gè)例子來(lái)說(shuō)，在傳統(tǒng)面向類(lèi)庫(kù)編程的時(shí)代，針對(duì)HTTP請(qǐng)求處理的流程牢牢控制在應(yīng)用程序手中。在引入框架之后，請(qǐng)求處理的控制權(quán)轉(zhuǎn)移到了框架手上。

二、好萊塢法則

在好萊塢，把簡(jiǎn)歷遞交給演藝公司后就只有回家等待。由演藝公司對(duì)整個(gè)娛樂(lè)項(xiàng)目的完全控制，演員只能被動(dòng)式的接受電影公司的工作，在需要的環(huán)節(jié)中，完成自己的演出?！安灰o我們打電話，我們會(huì)給你打電話(don‘t call us, we‘ll call you)”這是著名的好萊塢法則（ Hollywood Principle或者 Hollywood Low），IoC完美地體現(xiàn)了這一法則。

圖3 好萊塢法則

在IoC的應(yīng)用語(yǔ)境中，框架就像是掌握整個(gè)電影制片流程的電影公司，由于它是整個(gè)工作流程的實(shí)際控制者，所以只有它知道哪個(gè)環(huán)節(jié)需要哪些組件。應(yīng)用程序就像是演員，它只需要按照框架定制的規(guī)則注冊(cè)這些組件就可以了，因?yàn)榭蚣軙?huì)在適當(dāng)?shù)臅r(shí)機(jī)字典加載并執(zhí)行注冊(cè)的組件。

以熟悉的ASP.NET Core MVC或者ASP.NET MVC應(yīng)用開(kāi)發(fā)來(lái)說(shuō)，我們只需要按照約定規(guī)則（比如目錄結(jié)構(gòu)和命名等）定義相應(yīng)的Controller類(lèi)型和View文件就可以了。當(dāng)ASP.NET （Core ）MVC框架在進(jìn)行處理請(qǐng)求的過(guò)程中，它會(huì)根據(jù)解析生成的路由參數(shù)定義為對(duì)應(yīng)的Controller類(lèi)型，并按照預(yù)定義的規(guī)則找到我們定義的Controller，然后自動(dòng)創(chuàng)建并執(zhí)行它。如果定義在當(dāng)前Action方法需要呈現(xiàn)一個(gè)View，框架自身會(huì)根據(jù)預(yù)定義的目錄約定找到我們定義的View文件，并對(duì)它實(shí)施動(dòng)態(tài)編譯和執(zhí)行。整個(gè)流程處處體現(xiàn)了“框架Call應(yīng)用”的好萊塢法則。

總的來(lái)說(shuō)，我們?cè)谝粋€(gè)框架的基礎(chǔ)上進(jìn)行應(yīng)用開(kāi)發(fā)，就相當(dāng)于在一條調(diào)試好的流水線上生成某種商品，我們只需要在相應(yīng)的環(huán)節(jié)準(zhǔn)備對(duì)應(yīng)的原材料，最終下線的就是我們希望得到的最終產(chǎn)品。IoC幾乎是所有框架均具有的一個(gè)固有屬性，從這個(gè)意義上講，“IoC框架”的說(shuō)法其實(shí)是錯(cuò)誤的，世界上并沒(méi)有什么IoC框架，或者說(shuō)幾乎所有的框架都是IoC框架。

三、流程定制

我們采用IoC實(shí)現(xiàn)了流程控制從應(yīng)用程序向框架自身的反轉(zhuǎn)，但是這個(gè)被反轉(zhuǎn)的僅僅是一個(gè)泛化的流程，任何一個(gè)具體的應(yīng)用都可能需要對(duì)組成該流程的某些環(huán)節(jié)進(jìn)行定制。還是以我們的MVC框架來(lái)說(shuō)，可能默認(rèn)的請(qǐng)求處理流程只考慮到針對(duì)HTTP 1.1的支持，但是當(dāng)我們?cè)谠O(shè)計(jì)框架的時(shí)候應(yīng)該提供相應(yīng)的擴(kuò)展點(diǎn)來(lái)支持HTTP 2。作為一個(gè)Web框架，用戶(hù)認(rèn)證功能是必備的，但是框架自身不能限制于某一種或者幾種固定的認(rèn)證方式，應(yīng)該通過(guò)擴(kuò)展的方式讓用戶(hù)可以自由地定制任意的認(rèn)證模式。

我們可以說(shuō)得更加寬泛點(diǎn)。如圖4所示，我們將一個(gè)泛化的工作流程（A=>B=>C）被定義在框架之中，建立在該框架的兩個(gè)應(yīng)用需要對(duì)組成這個(gè)流程的某些環(huán)節(jié)進(jìn)行定制。比如步驟A和C可以被App1重用，但是步驟B卻需要被定制（B1），App2則重用步驟A和B，但是需要按照自己的方式處理步驟C。

圖4 應(yīng)用程序?qū)α鞒痰亩ㄖ?/p>

IoC將對(duì)流程的控制從應(yīng)用程序轉(zhuǎn)移到框架之中，框架利用一個(gè)引擎驅(qū)動(dòng)整個(gè)流程的執(zhí)行，應(yīng)用程序無(wú)需關(guān)心該工作流程的細(xì)節(jié)，它只需要啟動(dòng)這個(gè)引擎即可。但是這個(gè)引擎一旦被啟動(dòng)，框架就會(huì)完全按照預(yù)先編排好的流程進(jìn)行工作，如果應(yīng)用程序希望整個(gè)流程按照自己希望的方式被執(zhí)行，針對(duì)流程的定制一般在發(fā)生在啟動(dòng)引擎之前。

一般來(lái)說(shuō)，框架會(huì)以相應(yīng)的形式提供一系列的擴(kuò)展點(diǎn)，應(yīng)用程序則通過(guò)定義擴(kuò)展的方式實(shí)現(xiàn)對(duì)流程某個(gè)環(huán)節(jié)的定制。在引擎被啟動(dòng)之前，應(yīng)用程序?qū)⑺璧臄U(kuò)展注冊(cè)到框架之中。一旦引擎被正常啟動(dòng)，這些注冊(cè)的擴(kuò)展會(huì)自動(dòng)參與到整個(gè)流程的執(zhí)行過(guò)程中。

綜上所述，IoC一方面通過(guò)流程控制從應(yīng)用程序向框架的反轉(zhuǎn)實(shí)現(xiàn)了針對(duì)流程自身的重用，另一方面通過(guò)內(nèi)置的擴(kuò)展機(jī)制這個(gè)被重用的流程可能自由地被定制，這兩個(gè)因素決定了框架自身的價(jià)值。重用讓框架不僅僅是為應(yīng)用程序提供實(shí)現(xiàn)單一功能的API，而是提供一整套可執(zhí)行的解決方案，可定制則使我們可以為不同的應(yīng)用程序?qū)蚣苓M(jìn)行定制，這無(wú)疑讓框架可以使用到更多的應(yīng)用之中。
編輯：hfy