ASP.NET Core引入了Options模式，使用类来表示相关的设置组。简单的来说，就是用强类型的类来表达配置项，这带来了很多好处。利用了系统的依赖注入，并且还可以利用配置系统。它使我们可以采用依赖注入的方法直接使用绑定的一个POCO对象，这个POCO对象就叫做Options对象。也可以叫做配置对象。
以下大多内容来自官方文档，我只是个翻译官或者叫搬运工吧！
在appsetting.json文件增加如下配置
创建以下 PositionOptions 类：
调用 ConfigurationBinder.Bind 将 PositionOptions 类绑定到 Position 部分。然后就可以用了，当然这种方式在开发.NET Core种并不常用，一般采用依赖注入的方式注入。
使用 ConfigurationBinder.Get 可能比使用 ConfigurationBinder.Bind 更方便。
初学者会发现这个框架有3个主要的面向消费者的接口：IOptions、IOptionsMonitor以及IOptionsSnapshot。
这三个接口初看起来很类似，所以很容易引起困惑，什么场景下该用哪个接口呢？
IOptionsMonitor 和 IOptionsSnapshot 之间的区别在于：
命名选项：
appsettings.json文件
下面的类用于每个节，而不是创建两个类来绑定 TopItem:Month 和 TopItem:Year
依赖注入容器
服务应用
在配置选项时，可以通过以下两种方式通过依赖关系注入访问服务：
建议将配置委托传递给 Configure，因为创建服务较复杂。 在调用 Configure 时，创建类型等效于框架执行的操作。 调用 Configure 会注册临时泛型 IConfigureNamedOptions，它具有接受指定的泛型服务类型的构造函数。
appsettings.json 文件
下面的类绑定到 'MyConfig' 配置节，并应用若干 DataAnnotations 规则：
使用IValidateOptions更复杂的配置
IValidateOptions 允许将验证代码移出 StartUp 并将其移入类中。
使用前面的代码，使用以下代码在 Startup.ConfigureServices 中启用验证
使用 IPostConfigureOptions 设置后期配置。进行所有 IConfigureOptions 配置后运行后期配置
使用 PostConfigureAll 对所有配置实例进行后期配置
IOptions 和 IOptionsMonitor 可用于 Startup.Configure 中，因为在 Configure 方法执行之前已生成服务。
IOptions<>是单例，因此一旦生成了，除非通过代码的方式更改，它的值是不会更新的。
IOptionsMonitor<>也是单例，但是它通过IOptionsChangeTokenSource<> 能够和配置文件一起更新，也能通过代码的方式更改值。
IOptionsSnapshot<>是范围，所以在配置文件更新的下一次访问，它的值会更新，但是它不能跨范围通过代码的方式更改值，只能在当前范围（请求）内有效。
所以你应该根据你的实际使用场景来选择到底是用这三者中的哪一个。一般来说，如果你依赖配置文件，那么首先考虑IOptionsMonitor<>，如果不合适接着考虑IOptionsSnapshot<>，最后考虑IOptions<>。
有一点需要注意，在ASP.NET Core应用中IOptionsMonitor可能会导致同一个请求中选项的值不一致,当你正在修改配置文件的时候,这可能会引发一些奇怪的bug。
如果这个对你很重要，请使用IOptionsSnapshot，它可以保证同一个请求中的一致性，但是它可能会带来轻微的性能上的损失。如果你是在app启动的时候自己构造Options（比如在Startup类中）：
IOptions<>最简单，也许是一个不错的选择。
原文地址：https://www.cnblogs.com/zhanwei103/p/13161553.html
