在這個系列中，我將探索一下 .NET 6 中的一些新特性。已經(jīng)有很多關(guān)于 .NET 6 的內(nèi)容，包括很多來自 .NET 和 ASP.NET 團(tuán)隊本身的文章。在這個系列中，我將探索一下這些特性背后的一些代碼。

在這第一篇文章中，來研究一下 ConfigurationManager 類，講一下為什么要新增這個類，并看一下它的的一些實現(xiàn)代碼。

1什么是 ConfigurationManager

如果你的第一反應(yīng)是“什么是 ConfigurationManager”，那么不用擔(dān)心，你沒有錯過一個重要的公告：

加入 ConfigurationManager 是為了支持 ASP.NET Core 的新 WebApplication 模型，用于簡化 ASP.NET Core 的啟動代碼。然而 ConfigurationManager 在很大程度上是一個實現(xiàn)細(xì)節(jié)。它的引入是為了優(yōu)化一個特定的場景（我很快會講），但在大多數(shù)情況下，你不需要（也不會）知道你在使用它。

在我們討論 ConfigurationManager 本身之前，我們先來看看它所取代的東西和原因。

2.NET 5 中的配置

.NET 5 圍繞配置暴露了多種類型，但在你的應(yīng)用程序中直接使用的兩個主要類型是：

• IConfigurationBuilder - 用來添加配置源。在構(gòu)建器上調(diào)用 Build() 讀取每個配置源，并構(gòu)建最終的配置。

• IConfigurationRoot - 代表最終“構(gòu)建”好的配置。

IConfigurationBuilder 接口主要是一個圍繞配置源列表的封裝器。配置提供者通常包括擴(kuò)展方法（如 AddJsonFile() 和 AddAzureKeyVault()），將配置源添加到 Sources 列表中。

public?interface?IConfigurationBuilder {IDictionary<string, object> Properties { get; }IList<IConfigurationSource> Sources { get; }IConfigurationBuilder Add(IConfigurationSource source);IConfigurationRoot Build(); }

同時，IConfigurationRoot 代表最終“層”的配置值，結(jié)合了每個配置源的所有值，以提供所有配置值的最終“平面”視圖。

后者配置提供者（環(huán)境變量）覆蓋了前者配置提供者（appsettings.json、sharedsettings.json）添加的值。

在 .NET 5 及以前的版本中，IConfigurationBuilder 和 IConfigurationRoot 接口分別由 ConfigurationBuilder 和 ConfigurationRoot 實現(xiàn)。如果你直接使用這些類型，你可能會這樣做：

var builder = new ConfigurationBuilder();// add static values builder.AddInMemoryCollection(new Dictionary<string, string> {{ "MyKey", "MyValue" }, });// add values from a json file builder.AddJsonFile("appsettings.json");// create the IConfigurationRoot instance IConfigurationRoot config = builder.Build();string?value = config["MyKey"]; // get a value IConfigurationSection section = config.GetSection("SubSection"); //get a section

在一個典型的 ASP.NET Core 應(yīng)用程序中，你不會自己創(chuàng)建 ConfigurationBuilder，或調(diào)用 Build()，但除此之外，這就是幕后發(fā)生的事情。這兩種類型之間有明確的分離，而且在大多數(shù)情況下，配置系統(tǒng)運行良好，那么為什么我們在.NET 6 中需要一個新類型呢？

3.NET 5 中“部分構(gòu)建”配置的問題

這種設(shè)計的主要問題是在你需要“部分”構(gòu)建配置的時候。當(dāng)你將配置存儲在 Azure Key Vault 等服務(wù)中，甚至是數(shù)據(jù)庫中時，這是一個常見的問題。

例如，以下是在 ASP.NET Core 中的 ConfigureAppConfiguration() 里面從 Azure Key Vault 讀取 secrects 的建議方式：

.ConfigureAppConfiguration((context, config) => {// "normal" configuration etcconfig.AddJsonFile("appsettings.json");config.AddEnvironmentVariables();if (context.HostingEnvironment.IsProduction()){IConfigurationRoot partialConfig = config.Build(); // build partial configstring keyVaultName = partialConfig["KeyVaultName"]; // read value from configurationvar secretClient = new SecretClient(new Uri($"https://{keyVaultName}.vault.azure.net/"),new DefaultAzureCredential());config.AddAzureKeyVault(secretClient, new KeyVaultSecretManager()); // add an extra configuration source// The framework calls config.Build() AGAIN to build the final IConfigurationRoot} })

配置 Azure Key Vault 提供者需要一個配置值，所以你陷入了一個雞和蛋的問題--在你建立配置之前，你無法添加配置源。

解決辦法是：

• 添加“初始”配置值；

• 通過調(diào)用 IConfigurationBuilder.Build() 構(gòu)建“部分”配置結(jié)果；

• 從生成的 IConfigurationRoot 中檢索所需的配置值；

• 使用這些值來添加剩余的配置源；

• 框架隱含地調(diào)用 IConfigurationBuilder.Build()，生成最終的 IConfigurationRoot 并將其用于最終的應(yīng)用配置。

這整個過程有點亂，但它本身并沒有什么問題，那么缺點是什么呢？

缺點是我們必須調(diào)用 Build() 兩次：一次是只使用第一個源來構(gòu)建 IConfigurationRoot，另一次是使用所有源來構(gòu)建 IConfiguartionRoot，包括 Azure Key Vault 源。

在默認(rèn)的 ConfigurationBuilder 實現(xiàn)中，調(diào)用 Build() 會遍歷所有的源，加載提供者，并將這些傳遞給 ConfigurationRoot 的一個新實例。

public IConfigurationRoot Build() {var providers = new List<IConfigurationProvider>();foreach (IConfigurationSource source in Sources){IConfigurationProvider provider = source.Build(this);providers.Add(provider);}return?new ConfigurationRoot(providers); }

然后，ConfigurationRoot 依次循環(huán)遍歷這些提供者，并加載配置值。

public?class?ConfigurationRoot : IConfigurationRoot, IDisposable {private?readonly IList<IConfigurationProvider> _providers;private?readonly IList<IDisposable> _changeTokenRegistrations;public?ConfigurationRoot(IList<IConfigurationProvider> providers){_providers = providers;_changeTokenRegistrations = new List<IDisposable>(providers.Count);foreach (IConfigurationProvider p in providers){p.Load();_changeTokenRegistrations.Add(ChangeToken.OnChange(() => p.GetReloadToken(), () => RaiseChanged()));}}// ... remainder of implementation }

如果你在應(yīng)用啟動時調(diào)用 Build() 兩次，那么所有這些都會發(fā)生兩次。

一般來說，從配置源獲取數(shù)據(jù)一次以上并無大礙，但這是不必要的工作，而且經(jīng)常涉及到（相對緩慢的）文件讀取等。

這是一種常見的模式，所以在 .NET 6 中引入了一個新的類型來避免這種“重新構(gòu)建”，即 ConfigurationManager。

4.NET 6 中的配置管理器

作為 .NET 6 中“簡化”應(yīng)用模型的一部分，.NET 團(tuán)隊增加了一個新的配置類型--ConfigurationManager。這種類型同時實現(xiàn)了 IConfigurationBuilder 和 IConfigurationRoot。通過將這兩種實現(xiàn)結(jié)合在一個單一的類型中，.NET 6 可以優(yōu)化上一節(jié)中展示的常見模式。

有了 ConfigurationManager，當(dāng) IConfigurationSource 被添加時（例如當(dāng)你調(diào)用 AddJsonFile() 時），提供者被立即加載，配置被更新。這可以避免在部分構(gòu)建的情況下不得不多次加載配置源。

由于 IConfigurationBuilder 接口將源作為 IList<IConfigurationSource> 公開，因此實現(xiàn)這一點比聽起來要難一些：

public?interface?IConfigurationBuilder {IList<IConfigurationSource> Sources { get; }// .. other members }

從 ConfigurationManager 的角度來看，這個問題是 IList<> 暴露了 Add() 和 Remove() 函數(shù)。如果使用一個簡單的 List<>，消費者可以在 ConfigurationManager 不知道的情況下添加和刪除配置提供者。

為了解決這個問題，ConfigurationManager 使用一個自定義的 IList<> 實現(xiàn)。這包含對 ConfigurationManager 實例的引用，這樣任何變化都可以反映在配置中：

private?class?ConfigurationSources : IList<IConfigurationSource> {private?readonly List<IConfigurationSource> _sources = new();private?readonly ConfigurationManager _config;public?ConfigurationSources(ConfigurationManager config){_config = config;}public?void?Add(IConfigurationSource source){_sources.Add(source);_config.AddSource(source); // add the source to the ConfigurationManager}public?bool?Remove(IConfigurationSource source){var removed = _sources.Remove(source);_config.ReloadSources(); // reset sources in the ConfigurationManagerreturn removed;}// ... additional implementation }

通過使用一個自定義的 IList<> 實現(xiàn)，ConfigurationManager 確保每當(dāng)有新的源被添加時就調(diào)用 AddSource()。這就是 ConfigurationManager 的優(yōu)勢所在：調(diào)用 AddSource() 可以立即加載源：

ublic class?ConfigurationManager {private?void?AddSource(IConfigurationSource source){lock (_providerLock){IConfigurationProvider provider = source.Build(this);_providers.Add(provider);provider.Load();_changeTokenRegistrations.Add(ChangeToken.OnChange(() => provider.GetReloadToken(), () => RaiseChanged()));}RaiseChanged();} }

這個方法立即在 IConfigurationSource 上調(diào)用 Build 來創(chuàng)建 IConfigurationProvider，并將其添加到提供者列表中。

接下來，該方法調(diào)用 IConfigurationProvider.Load()。這將把數(shù)據(jù)加載到提供者中，（例如從環(huán)境變量、JSON 文件或 Azure Key Vault），這是“昂貴”的步驟，而這一切就是為了加載數(shù)據(jù) 在“正?！鼻闆r下，你只需向 IConfigurationBuilder 添加源，并可能需要多次構(gòu)建它，這就給出了“最佳”方法——源被加載一次，且只有一次。

ConfigurationManager 中 Build() 的實現(xiàn)現(xiàn)在什么都沒做，只是返回它自己：

IConfigurationRoot IConfigurationBuilder.Build() => this;

當(dāng)然，軟件開發(fā)是所有關(guān)于權(quán)衡的問題。如果你只添加源，那么在添加源的時候遞增構(gòu)建源就很有效。然而，如果你調(diào)用任何其他 IList<> 函數(shù)，如 Clear()、Remove() 或索引器，ConfigurationManager 就必須調(diào)用 ReloadSources()：

private?void?ReloadSources() {lock (_providerLock){DisposeRegistrationsAndProvidersUnsynchronized();_changeTokenRegistrations.Clear();_providers.Clear();foreach (var source in _sources){_providers.Add(source.Build(this));}foreach (var p in _providers){p.Load();_changeTokenRegistrations.Add(ChangeToken.OnChange(() => p.GetReloadToken(), () => RaiseChanged()));}}RaiseChanged(); }

正如你所看到的，如果任何一個源改變了，ConfigurationManager 必須刪除所有的東西并重新開始，迭代每個源，重新加載它們。如果你要對配置源進(jìn)行大量的操作，這很快就會變得很昂貴，而且會完全否定 ConfigurationManager 的原始優(yōu)勢。

當(dāng)然，刪除源是非常罕見的，所以 ConfigurationManager 是為最常見的情況而優(yōu)化的。誰能猜到呢？

下表給出了使用 ConfigurationBuilder 和 ConfigurationManager 的各種操作的相對成本的最終總結(jié)：

5是否需關(guān)心 ConfigurationManager

那么讀了這么多，你是否應(yīng)該關(guān)心你是使用 ConfigurationManager 還是 ConfigurationBuilder？

也許不應(yīng)該。

在 .NET 6 中引入的新的 WebApplicationBuilder 使用 ConfigurationManager，它優(yōu)化了我上面描述的使用情況，即你需要“部分構(gòu)建”你的配置。

然而，ASP.NET Core 早期版本中引入的 WebHostBuilder 或 HostBuilder 在 .NET 6 中仍然非常受支持，它們繼續(xù)在幕后使用 ConfigurationBuilder 和 ConfigurationRoot 類型。

我認(rèn)為唯一需要注意的情況是，如果你在某個地方依賴 IConfigurationBuilder 或 IConfigurationRoot 作為具體類型的 ConfigurationBuilder 或 ConfigurationRoot。這在我看來是非常不太可能發(fā)生的，如果你依賴這一點，我很想知道原因。

但除了這個小眾的例外，“老”類型不會消失，所以沒有必要擔(dān)心。如果你需要進(jìn)行“部分構(gòu)建”，并且你使用了新的 WebApplicationBuilder，那么你的應(yīng)用程序?qū)懈叩男阅?#xff0c;這一點你應(yīng)該感到高興。

6總結(jié)

在這篇文章中，我描述了在 .NET 6 中引入的新的 ConfigurationManager 類型，并在最小(Minimal) API 示例中被新的 WebApplicationBuilder 所使用。引入 ConfigurationManager 是為了優(yōu)化一種常見的情況，即你需要“部分構(gòu)建”配置。這通常是因為配置提供者本身需要一些配置，例如，從 Azure Key Vault 加載 secrects，需要配置表明要使用哪個 Vault 庫。

ConfigurationManager 優(yōu)化了這種情況：它在添加源時立即加載，而不是等到你調(diào)用 Build()。這就避免了在“部分構(gòu)建”情況下“重建”配置的需要，其代價是其他不常見操作（如刪除一個源）可能變得更昂貴的。

原文：bit.ly/3227vka
作者：Andrew Lock
翻譯：精致碼農(nóng)

總結(jié)

以上是生活随笔為你收集整理的[探索 .NET 6]01 揭开 ConfigurationManager 的面纱的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。