关于c#:聊聊ASPNET-Core中的配置

作为软件开发人员，咱们当然喜爱一些可配置选项，尤其是当它容许咱们扭转应用程序的行为而无需批改或编译咱们的应用程序时。无论你是应用新的还是旧的.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...