在 ASP.NET Core 程序啓動前運行你的代碼

一、前言

在進行 Web 項目開發的過程中,可能會存在一些需要經常訪問的靜態數據,針對這種在程序運行過程中可能幾乎不會發生變化的數據,我們可以嘗試在程序運行前寫入到緩存中,這樣在系統後續使用時就可以直接從緩存中進行獲取,從而減緩因爲頻繁讀取這些靜態數據造成的應用數據庫服務器的巨大承載壓力。

既然需要在程序運行前將靜態數據寫入到緩存中,毫無疑問我們需要在程序運行前執行一些自定義功能的代碼,那麼在本章中,我將會介紹如何在 ASP.NET Core 項目中,實現在程序啓動前執行某些特定功能的代碼。

 

二、Step by Step

1、先說結論

因爲這一篇文章更多的是在說明我在解決這個問題時的一步步思考,並沒有涉及到代碼的編寫,所以下面的內容可能對你的幫助並不是很大,所以這裏提前將實現的方式告訴大家。對於這個問題來說,只需要將我們想要執行的代碼放到下面代碼中註釋所在的位置,即可實現我們的需求。

public class Program
{
  public static void Main(string[] args)
  {
    var host = CreateHostBuilder(args).Build();
        
    // do what you want
        
    host.Run();
  }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>();
            });
}

2、前車之鑑

在嘗試如何在 ASP.NET Core 中實現這一功能需求前,我們可以看看在 .NET Framework 中如何實現這一功能,是不是可以對我們在後續的功能實現中提供某些借鑑。

對於採用 .NET Framework 的應用程序來說,項目創建後會生成一個 Global.asax 文件,在這個類文件中存在着 Application_Start 這樣的一個方法,而 Application_Start 這個方法實際上是在當應用程序接收到第一個 HTTP 請求時觸發,也就是說,當系統運行後第一次接收到用戶的請求,就會觸發 Application_Start 中的代碼邏輯,後續不管再接收到多少的請求,都不會再觸發該方法。

例如在這個基於 .NET Framework 構建的 MVC 項目模板中,在程序運行前需要執行註冊路由信息、註冊過濾器、註冊使用 bundle 壓縮後的 js、css 文件等等。

但是在 ASP.NET Core 項目中,並沒有原生存在這樣的方法,那麼我們如何在 ASP.NET Core 應用中自己動手實現類似的功能呢?

3、後事之師

瞭解了在之前版本中的實現方式,現在我們仔細看看 Application_Start 這個方法中執行的每行代碼的功能,是不是特別像我們在 ASP.NET Core 項目中使用的各種中間件?

然而,如果你有使用過 ASP.NET Core 後就會知道,ASP.NET Core 中的中間件是會在每次請求時都會觸發的,雖然我們可以在我們自定義的中間件中設置緩存中不存在數據就寫入,存在就直接跳過的代碼邏輯,但是既然除了第一次訪問時纔會真正執行該中間件的功能,後面完全用不到,因此,對於我這種略微強迫症的童鞋來說,這個真的不能忍。。。

既然中間件不可以,而我們需要的僅僅是隻運行一次,提到 .NET Core,不知道你的第一印象是什麼,對於我個人來說,無處不在的依賴注入,可能是我在 18 年開始學習 .NET Core 時的第一印象。我們知道,對於 .NET Core 中原生的依賴注入組件,存在着三種生命週期:Singleton、Scoped 以及 Transient,對於這三種生命週期的具體解釋,還是推薦博客園裏蔣金楠老師的一篇文章(電梯直達)。

對於採用 Singleton 方式注入的服務來說,因爲是一種類似於全局單例的形式,不管後續從何處進行訪問,都會訪問的是同一個實例,那麼,這裏是不是就可以在此基礎上實現我們的需求了呢?

很不幸,這裏其實是有個很嚴重的邏輯上的問題的,依賴注入最終的目的是爲了實現將我們定義的服務契約與實現進行解耦,實現服務的消費者只需要告訴依賴注入容器自己所需要服務的類型(服務接口 or 抽象服務類),就能自動得到與之匹配的服務實例。

簡單點說就是,消費方要告訴服務提供方你要開始使用某個服務了,我才能給你提供對應的服務,就像我們去飯店吃飯,在點了菜後,沒有必要關心廚師是用天然氣 or 煤氣給你燒的菜,但是能不能上菜的關鍵在於我們有沒有點菜。因此,這個問題最終還是落在了我們應該在程序中的什麼地方去調用我們設定好的方法。

繞了一圈,似乎我們的想法越來越偏,離我們想要實現的越來越遠,既然路偏了,那就直接回到起點吧,拋棄我們在 .NET Framework 項目中的經驗,重新從 ASP.NET Core 項目的啓動流程開始看起。

在 ASP.NET Core 應用的啓動過程中存在着兩個非常重要的對象,對應到我們採用的 ASP.NET Core 3.X 的項目中則是 Host 以及 HostBuilder。這裏的 Host 就是承載我們 Web 應用運行的載體,而 HostBuilder 則是用來構建 Host 對象的。

PS:因爲 ASP.NET Core 3.0 開始加入了 對於 gRPC 框架和 Windows Service 的支持,同時爲了與其它非 Web 服務器方案進行集成,因此將原來的 WebHost 和 WebHostBuilder 替換成了新的通用主機(generic-host)配置的模式 。當然,在 3.X 版本你還是可以使用 WebHost 和 WebHostBuilder 的,不過當然是不推薦的。

因爲對於 ASP.NET Core 應用程序來說,本質上其實只是一個控制檯應用,所以現在我們來看看對於一個控制檯應用中最重要的文件:Program.cs, Program 類中的代碼如下所示。

public class Program
{
    public static void Main(string[] args)
    {
        CreateHostBuilder(args).Build().Run();
    }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>();
            });
}

代碼很少,功能也很簡單,簡單來說,在 Main 方法中構建 HostBuilder 對象,然後去運行它,達到啓動我們 Web 應用宿主的目的。

當然,在構建 HostBuilder 對象的過程中,會配置 Kestrel 服務器,會設置 ContentRoot,會加載配置文件等等一系列的動作,因爲自己水平太次,嘗試了一下,還是解釋不好,如果你想要深入瞭解的話,建議配合博客園裏面的這兩篇文章一起食用(200行代碼,7個對象——讓你瞭解 ASP.NET Core 框架的本質ASP.NET Core 2.0 : 七.一張圖看透啓動背後的祕密)。雖然參考文章中都是基於 ASP.NET Core 2.X 版本進行解釋說明的,但其實最終的差異不是很大。

不知你是否找到了這個類中對於我們最重要的一點,在 Main 方法中,我們是先構建、再去運行,因此,我們是不是可以在構建完成後,先等一等,把我們想要實現的功能先調用了,再去運行我們的程序。嗯,讓我們改造下 Main 方法中的代碼。

public class Program
{
    public static void Main(string[] args)
    {
    var host = CreateHostBuilder(args).Build();

    // Get logger
    //
    var logger = host.Services.GetRequiredService<ILogger<Program>>();
    logger.LogInformation("haha, I ran before web host starting");

    host.Run();
  }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>();
            });
}

從上面的圖中可以看到,在我們的 Web 應用的宿主程序還未啓動之前,控制檯就已經打印出了我們自己設定的信息,之後,纔是啓動我們的 Web 應用,這裏是請求我們的 API 接口。同時可以發現,在模擬多次請求時,並不會再次觸發我們預設的事件。

 

三、總結

這一篇文章中並沒有包含代碼,更多的是針對我之前在開發中遇到的一個問題,自己在解決過程中的一個案例說明,希望可以在你以後遇到這類問題時可以提供一些幫助。離 2020 年的農曆新年也沒有幾天了,按目前的進度,估計就是年前的最後一篇博客了,我也要收拾收拾心情,準備過年了。最後,送大家一張表情包,獻給得知你是最後一個放假的童鞋,哈哈哈,提前祝大家新年快樂丫。

 

四、參考

  1. [ASP.NET Core 3框架揭祕] 依賴注入[8]:服務實例的生命週期
  2. 200行代碼,7個對象——讓你瞭解 ASP.NET Core 框架的本質
  3. ASP.NET Core 2.0 : 七.一張圖看透啓動背後的祕密
  4. ASP.NET Core 3.0 的新增功能
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章