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

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

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

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

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

我們通過一個具體事例來說明傳統(tǒng)的設(shè)計(jì)在采用了IoC之后針對流程的控制是如何實(shí)現(xiàn)反轉(zhuǎn)的。比如說現(xiàn)在設(shè)計(jì)一個針對Web的MVC類庫，我們不妨將其命名為MvcLib。簡單起見，這個類庫中只包含如下這個同名的靜態(tà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個方法幫助我們完成整個HTTP請求流程中的5個核心任務(wù)。具體來說，ListenAsync方法啟動一個監(jiān)聽器并將其綁定到指定的地址進(jìn)行HTTP請求的監(jiān)聽，抵達(dá)的請求通過ReceiveAsync方法進(jìn)行接收，我們將接收到的請求通過一個Request對象來表示。CreateControllerAsync方法根據(jù)接收到的請求解析并激活請求的目標(biāo)Controller對象。ExecuteControllerAsync方法執(zhí)行激活的Controller并返回一個表示視圖的View對象。RenderViewAsync最終將View對象轉(zhuǎn)換成HTML并作為當(dāng)前請求響應(yīng)的內(nèi)容返回給請求的客戶端。

現(xiàn)在我們在這個MvcLib的基礎(chǔ)上創(chuàng)建一個真正的MVC應(yīng)用，那么除了按照MvcLib的規(guī)范自定義具體的Controller和View之外，我們還需要自行控制從請求的監(jiān)聽與接收、Controller的激活與執(zhí)行以及View的最終呈現(xiàn)在內(nèi)的整個流程，這樣一個執(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);
        }
    }    
}

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

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

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

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

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

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

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

二、好萊塢法則

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

圖3 好萊塢法則

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

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

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

三、流程定制

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

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

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

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

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

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