专门做二手手机的网站吗,求一个手机能看的2022,广州公司网站建设,北京网站建设找华网天下在这个系列中#xff0c;我将探索一下 .NET 6 中的一些新特性。已经有很多关于 .NET 6 的内容#xff0c;包括很多来自 .NET 和 ASP.NET 团队本身的文章。在这个系列中#xff0c;我将探索一下这些特性背后的一些代码。在这第一篇文章中#xff0c;来研究一下 Configuratio… 在这个系列中我将探索一下 .NET 6 中的一些新特性。已经有很多关于 .NET 6 的内容包括很多来自 .NET 和 ASP.NET 团队本身的文章。在这个系列中我将探索一下这些特性背后的一些代码。在这第一篇文章中来研究一下 ConfigurationManager 类讲一下为什么要新增这个类并看一下它的的一些实现代码。1什么是 ConfigurationManager如果你的第一反应是“什么是 ConfigurationManager”那么不用担心你没有错过一个重要的公告加入 ConfigurationManager 是为了支持 ASP.NET Core 的新 WebApplication 模型用于简化 ASP.NET Core 的启动代码。然而 ConfigurationManager 在很大程度上是一个实现细节。它的引入是为了优化一个特定的场景我很快会讲但在大多数情况下你不需要也不会知道你在使用它。在我们讨论 ConfigurationManager 本身之前我们先来看看它所取代的东西和原因。2.NET 5 中的配置.NET 5 围绕配置暴露了多种类型但在你的应用程序中直接使用的两个主要类型是IConfigurationBuilder - 用来添加配置源。在构建器上调用 Build() 读取每个配置源并构建最终的配置。IConfigurationRoot - 代表最终“构建”好的配置。IConfigurationBuilder 接口主要是一个围绕配置源列表的封装器。配置提供者通常包括扩展方法如 AddJsonFile() 和 AddAzureKeyVault()将配置源添加到 Sources 列表中。public interface IConfigurationBuilder
{IDictionarystring, object Properties { get; }IListIConfigurationSource Sources { get; }IConfigurationBuilder Add(IConfigurationSource source);IConfigurationRoot Build();
}同时IConfigurationRoot 代表最终“层”的配置值结合了每个配置源的所有值以提供所有配置值的最终“平面”视图。后者配置提供者环境变量覆盖了前者配置提供者appsettings.json、sharedsettings.json添加的值。在 .NET 5 及以前的版本中IConfigurationBuilder 和 IConfigurationRoot 接口分别由 ConfigurationBuilder 和 ConfigurationRoot 实现。如果你直接使用这些类型你可能会这样做var builder new ConfigurationBuilder();// add static values
builder.AddInMemoryCollection(new Dictionarystring, 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 应用程序中你不会自己创建 ConfigurationBuilder或调用 Build()但除此之外这就是幕后发生的事情。这两种类型之间有明确的分离而且在大多数情况下配置系统运行良好那么为什么我们在.NET 6 中需要一个新类型呢3.NET 5 中“部分构建”配置的问题这种设计的主要问题是在你需要“部分”构建配置的时候。当你将配置存储在 Azure Key Vault 等服务中甚至是数据库中时这是一个常见的问题。例如以下是在 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 提供者需要一个配置值所以你陷入了一个鸡和蛋的问题--在你建立配置之前你无法添加配置源。解决办法是添加“初始”配置值通过调用 IConfigurationBuilder.Build() 构建“部分”配置结果从生成的 IConfigurationRoot 中检索所需的配置值使用这些值来添加剩余的配置源框架隐含地调用 IConfigurationBuilder.Build()生成最终的 IConfigurationRoot 并将其用于最终的应用配置。这整个过程有点乱但它本身并没有什么问题那么缺点是什么呢缺点是我们必须调用 Build() 两次一次是只使用第一个源来构建 IConfigurationRoot另一次是使用所有源来构建 IConfiguartionRoot包括 Azure Key Vault 源。在默认的 ConfigurationBuilder 实现中调用 Build() 会遍历所有的源加载提供者并将这些传递给 ConfigurationRoot 的一个新实例。public IConfigurationRoot Build()
{var providers new ListIConfigurationProvider();foreach (IConfigurationSource source in Sources){IConfigurationProvider provider source.Build(this);providers.Add(provider);}return new ConfigurationRoot(providers);
}然后ConfigurationRoot 依次循环遍历这些提供者并加载配置值。public class ConfigurationRoot : IConfigurationRoot, IDisposable
{private readonly IListIConfigurationProvider _providers;private readonly IListIDisposable _changeTokenRegistrations;public ConfigurationRoot(IListIConfigurationProvider providers){_providers providers;_changeTokenRegistrations new ListIDisposable(providers.Count);foreach (IConfigurationProvider p in providers){p.Load();_changeTokenRegistrations.Add(ChangeToken.OnChange(() p.GetReloadToken(), () RaiseChanged()));}}// ... remainder of implementation
}如果你在应用启动时调用 Build() 两次那么所有这些都会发生两次。一般来说从配置源获取数据一次以上并无大碍但这是不必要的工作而且经常涉及到相对缓慢的文件读取等。这是一种常见的模式所以在 .NET 6 中引入了一个新的类型来避免这种“重新构建”即 ConfigurationManager。4.NET 6 中的配置管理器作为 .NET 6 中“简化”应用模型的一部分.NET 团队增加了一个新的配置类型--ConfigurationManager。这种类型同时实现了 IConfigurationBuilder 和 IConfigurationRoot。通过将这两种实现结合在一个单一的类型中.NET 6 可以优化上一节中展示的常见模式。有了 ConfigurationManager当 IConfigurationSource 被添加时例如当你调用 AddJsonFile() 时提供者被立即加载配置被更新。这可以避免在部分构建的情况下不得不多次加载配置源。由于 IConfigurationBuilder 接口将源作为 IListIConfigurationSource 公开因此实现这一点比听起来要难一些public interface IConfigurationBuilder
{IListIConfigurationSource Sources { get; }// .. other members
}从 ConfigurationManager 的角度来看这个问题是 IList 暴露了 Add() 和 Remove() 函数。如果使用一个简单的 List消费者可以在 ConfigurationManager 不知道的情况下添加和删除配置提供者。为了解决这个问题ConfigurationManager 使用一个自定义的 IList 实现。这包含对 ConfigurationManager 实例的引用这样任何变化都可以反映在配置中private class ConfigurationSources : IListIConfigurationSource
{private readonly ListIConfigurationSource _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 实现ConfigurationManager 确保每当有新的源被添加时就调用 AddSource()。这就是 ConfigurationManager 的优势所在调用 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 上调用 Build 来创建 IConfigurationProvider并将其添加到提供者列表中。接下来该方法调用 IConfigurationProvider.Load()。这将把数据加载到提供者中例如从环境变量、JSON 文件或 Azure Key Vault这是“昂贵”的步骤而这一切就是为了加载数据 在“正常”情况下你只需向 IConfigurationBuilder 添加源并可能需要多次构建它这就给出了“最佳”方法——源被加载一次且只有一次。ConfigurationManager 中 Build() 的实现现在什么都没做只是返回它自己IConfigurationRoot IConfigurationBuilder.Build() this;当然软件开发是所有关于权衡的问题。如果你只添加源那么在添加源的时候递增构建源就很有效。然而如果你调用任何其他 IList 函数如 Clear()、Remove() 或索引器ConfigurationManager 就必须调用 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 必须删除所有的东西并重新开始迭代每个源重新加载它们。如果你要对配置源进行大量的操作这很快就会变得很昂贵而且会完全否定 ConfigurationManager 的原始优势。当然删除源是非常罕见的所以 ConfigurationManager 是为最常见的情况而优化的。谁能猜到呢下表给出了使用 ConfigurationBuilder 和 ConfigurationManager 的各种操作的相对成本的最终总结5是否需关心 ConfigurationManager那么读了这么多你是否应该关心你是使用 ConfigurationManager 还是 ConfigurationBuilder也许不应该。在 .NET 6 中引入的新的 WebApplicationBuilder 使用 ConfigurationManager它优化了我上面描述的使用情况即你需要“部分构建”你的配置。然而ASP.NET Core 早期版本中引入的 WebHostBuilder 或 HostBuilder 在 .NET 6 中仍然非常受支持它们继续在幕后使用 ConfigurationBuilder 和 ConfigurationRoot 类型。我认为唯一需要注意的情况是如果你在某个地方依赖 IConfigurationBuilder 或 IConfigurationRoot 作为具体类型的 ConfigurationBuilder 或 ConfigurationRoot。这在我看来是非常不太可能发生的如果你依赖这一点我很想知道原因。但除了这个小众的例外“老”类型不会消失所以没有必要担心。如果你需要进行“部分构建”并且你使用了新的 WebApplicationBuilder那么你的应用程序将会有更高的性能这一点你应该感到高兴。6总结在这篇文章中我描述了在 .NET 6 中引入的新的 ConfigurationManager 类型并在最小(Minimal) API 示例中被新的 WebApplicationBuilder 所使用。引入 ConfigurationManager 是为了优化一种常见的情况即你需要“部分构建”配置。这通常是因为配置提供者本身需要一些配置例如从 Azure Key Vault 加载 secrects需要配置表明要使用哪个 Vault 库。ConfigurationManager 优化了这种情况它在添加源时立即加载而不是等到你调用 Build()。这就避免了在“部分构建”情况下“重建”配置的需要其代价是其他不常见操作如删除一个源可能变得更昂贵的。原文bit.ly/3227vka作者Andrew Lock翻译精致码农
