共计 2988 个字符，预计需要花费 8 分钟才能阅读完成。
作为软件开发人员，咱们当然喜爱一些可配置选项，尤其是当它容许咱们扭转应用程序的行为而无需批改或编译咱们的应用程序时。无论你是应用新的还是旧的.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。
原文链接：https://khalidabuhakmeh.com/a…
