聊聊ASP.NET Core中的配置

• 2021 年 2 月 20 日
• 筆記

​作為軟件開發人員，我們當然喜歡一些可配置選項，尤其是當它允許我們改變應用程序的行為而無需修改或編譯我們的應用程序時。無論你是使用新的還是舊的.NET時，可能希望利用json文件的配置。在這篇文章中，我們將探討讀取配置所需的必要步驟以及使用這些值。

.NET的配置歷史

對於那些ASP.NET老兵，你可能還記得wen.config。雖然它沒有完全被拋棄，但它在ASP.NET Core中扮演着不那麼重要的角色。web.config是一個基於XML的文件，用於配置IIS的主機環境。在這個文件中，我們可以放置應用程序設置、加載額外的web模塊、註冊處理程序等等。

另一個限制是web.config更改後將迫使應用程序重新啟動。更改可以很簡單，如添加新的應用程序設置，也可以很複雜，如向請求管道添加新模塊。ASP.NET應用程序必須重新加載，以確保邏輯一致性。開發人員可以將所有設置通過ConfigurationManager訪問。坦率地說，隨着時間的推移，開發人員將重新啟動看作是一種功能，而不是一種障礙，使用它來重置陷入故障狀態的應用程序。

現在的ASP.NET Core配置

ASP.NET Core看到了圍繞配置產生主要問題，並試圖通過以下三方面為開發人員改進：

• 除了XML之外，還支持其他形式的配置格式。
• 用依賴注入(DI)的友好方法替換ConfigurationManager。
•  配置熱更改，可以立即在訪問的代碼中發生。

這些變化反映了更先進的設置，並且對本地雲的web應用程序更友好。應用程序配置可以來自多個位置，可擴展性使開發人員更容易避免自定義解決方案。

隨着.NET採用async/await和異步編程，使用單例可能會導致死鎖和性能開銷。使DI支持配置後，給開發人員提供了更多的方式來使用設置依賴項，並將這些數據與任何源解耦。它還可以在不訪問ConfigurationManager或web.config的情況下測試配置設置。

冷啟動是所有用戶的敵人，它會創造令人沮喪的體驗。無需重新啟動就可以進行更改的能力確保了更好的運行時體驗。

看看具體代碼

目前，我們已經討論了配置的歷史和當前狀態，但是讓我們跳到實際使用環節。

第一步是創建一個從配置提供程序讀取設置的數據類。ASP.NET Core提供了多個開箱即用的功能，但最常用的是JSON配置提供程序。該類需要包含與JSON部分相同的結構。

public class HelloWorldOptions{
  public string Text { get; set; }
}

下一部分是講述ASP.NET Core如何綁定HelloWorldOptions類。我們可以使用BindConfiguration方法做到這一點。

public void ConfigureServices(IServiceCollection services){
    services.AddOptions<HelloWorldOptions>()
            .BindConfiguration("HelloWorld");
}

字符串HelloWorld表示appsettings.json文件中的部分。

{
  "HelloWorld" : {
    "Text": "Hello, Khalid!"
  },
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  },
  "AllowedHosts": "*"
}

很好，現在我們準備好使用我們的配置信息了。接下來就有點讓人困惑了。我們有三個接口可供選擇:

• IOptions<T>
• IOptionsSnapshot<T>
• IOptionsMonitor<T>

每個接口都包裝了我們的配置數據，並為我們提供了略微不同的生命周期。

IOptions< T>被註冊為一個單例，因此所有的值都被檢索一次並存儲在ASP.NET Core應用程序的內存。在應用程序啟動後，這種方法無法讀取任何更新的配置。註冊為單例意味着ASP.NET可以將接口注入到任何依賴項中，而不必擔心捕獲它或導致內存泄漏問題。這個版本很可能是大多數人會使用的。

IOptionsSnapshot< T>具有作用域生存期。ASP.NET Core將對每個HTTP請求重新檢查一次。

緩存每個請求的實例，直到用戶收到響應。這個方法對於那些希望動態更改配置但仍然需要通過當前管道進行刷新的請求的人非常有用。這個版本有助於使用切換配置，而無需重新加載應用程序。

最後,IOptionsMonitor< T>與IOptionsSnapshot<T>很相似，卻是單例生命周期。IOptionsMonitor方法對於應該立即處理的關鍵數據更改非常有用。長期存在的後台服務可能希望使用IOptionsMonitor繼續接收配置更改，但不需要支付昂貴的對象創建成本。

既然我們知道了每個接口的優點，我們就可以使用我們的配置了。在啟動時找到的Configure方法中，讓我們添加一個新的GET終結點。

public void Configure(IApplicationBuilder app, IWebHostEnvironment env){
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
​
    app.UseRouting();
​
    app.UseEndpoints(endpoints =>
    {
        endpoints.MapGet("/", async context =>
        {
            var options = 
                context
                    .RequestServices
                    .GetRequiredService<IOptionsSnapshot<HelloWorldOptions>>()
                    .Value;
            
            await context.Response.WriteAsync(options.Text);
        });
    });
}

注意，在我們的代碼中，我們使用的是IOptionsSnapshot。通過實例將允許我們更新配置，而不需要重新啟動我們的應用程序。啟動應用程序時，我們應該看到配置值。更改配置將更改請求的結果。

{
  "HelloWorld" : {
    "Text": "Hello, World!"
  },
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  },
  "AllowedHosts": "*"
}

重新加載後，我們現在看到的內容：

Hello, World!

這很有效，而且我們不需要為配置中的微小更改支付啟動成本。

總結

最初使用ASP.NET Core中的配置可能會讓人感到困惑。微軟文檔對IOption接口有一個詳細的解釋。大多數情況下，人們應該使用IOptions<T>，因為它可能是性能最好的。也就是說，如果我們想要熱加載設置的能力，如果我們想要請求一致性，IOptionsSnapshot是最好的。

最後，如果你的應用嚴重依賴單例生存期，仍然需要熱加載設置，考慮IOptionsMonitor。

原文鏈接：//khalidabuhakmeh.com/aspnet-core-ioptions-configuration