IOptions、IOptionsMonitor以及IOptionsSnapshot

背景

asp.net core引入了options模式，使用类来表示相关的设置组。简单的来说，就是用强类型的类来表达配置项，这带来了很多好处。
初学者会发现这个框架有3个主要的面向消费者的接口：ioptions<toptions>、ioptionsmonitor<toptions>以及ioptionssnapshot<toptions>。
这三个接口初看起来很类似，所以很容易引起困惑，什么场景下该用哪个接口呢？

示例

我们先从一小段代码着手（testoptions类只有一个字符串属性name，代码略）：

 1 class program
 2 {
 3     static void main(string[] args)
 4     {
 5         var builder = new configurationbuilder();
 6         builder.addjsonfile("appsettings.json", optional: true, reloadonchange: true); //注意最后一个参数值，true表示配置文件更改时会重新加载。
 7         var configuration = builder.build();
 8         var services = new servicecollection();
 9         services.addoptions();
10         services.configure<testoptions>(configuration); //这里通过配置文件绑定testoptions
11         var provider = services.buildserviceprovider();
12         console.writeline("修改前：");
13         print(provider);
14 
15         change(provider); //使用代码修改options值。
16         console.writeline("使用代码修改后：");
17         print(provider);
18         
19         console.writeline("请修改配置文件。");
20         console.readline(); //等待手动修改appsettings.json配置文件。
21         console.writeline("修改appsettings.json文件后：");
22         print(provider);
23     }
24 
25     static void print(iserviceprovider provider)
26     {
27         using(var scope = provider.createscope())
28         {
29             var sp = scope.serviceprovider;
30             var options1 = sp.getrequiredservice<ioptions<testoptions>>();
31             var options2 = sp.getrequiredservice<ioptionsmonitor<testoptions>>();
32             var options3 = sp.getrequiredservice<ioptionssnapshot<testoptions>>();
33             console.writeline("ioptions值: {0}", options1.value.name);
34             console.writeline("ioptionsmonitor值: {0}", options2.currentvalue.name);
35             console.writeline("ioptionssnapshot值: {0}", options3.value.name);
36             console.writeline();
37         }
38     }
39 
40     static void change(iserviceprovider provider)
41     {
42         using(var scope = provider.createscope())
43         {
44             var sp = scope.serviceprovider;
45             sp.getrequiredservice<ioptions<testoptions>>().value.name = "ioptions test 1";
46             sp.getrequiredservice<ioptionsmonitor<testoptions>>().currentvalue.name = "ioptionsmonitor test 1";
47             sp.getrequiredservice<ioptionssnapshot<testoptions>>().value.name = "ioptionssnapshot test 1";
48         }
49     }
50 }

appsettings.json文件：

{
    "name": "test 0"
}

上面的代码，首先从appsettings.json文件读取配置，然后向容器注册依赖配置文件的testoptions，接着分别打印ioptions<>,ioptionsmonitor<>和ioptionssnapshot<>的值。

接着通过代码来修改testoptions的值，打印。
然后通过修改appsettings.json文件来修改testoptions的值，打印。

注意，我们仅注册了一次testoptions，却可以分别通过ioptions<>,ioptionsmonitor<>和ioptionssnapshot<>接口来获取testoptions的值。

如果我们把appsettings.json文件中name的值修改为test 2，那么上面这段代码的输出是这样的：

分析

我们可以看到第一次通过代码修改ioptions<>和ioptionsmonitor<>的值后，再次打印都被更新了，但是ioptionssnapshot<>没有，为什么呢？
让我们从options框架的源代码着手，理解为什么会这样。
当我们需要使用options模式时，我们都会调用定义在optionsservicecollectionextensions类上的扩展方法addoptions(this iservicecollection services)。

var services = new servicecollection();
services.addoptions();

我们观察addoptions方法的实现：

public static iservicecollection addoptions(this iservicecollection services)
{
    if (services == null)
    {
        throw new argumentnullexception(nameof(services));
    }

    services.tryadd(servicedescriptor.singleton(typeof(ioptions<>), typeof(optionsmanager<>)));
    services.tryadd(servicedescriptor.scoped(typeof(ioptionssnapshot<>), typeof(optionsmanager<>)));
    services.tryadd(servicedescriptor.singleton(typeof(ioptionsmonitor<>), typeof(optionsmonitor<>)));
    services.tryadd(servicedescriptor.transient(typeof(ioptionsfactory<>), typeof(optionsfactory<>)));
    services.tryadd(servicedescriptor.singleton(typeof(ioptionsmonitorcache<>), typeof(optionscache<>)));
    return services;
}

从上面的代码我们可以得知，ioptions<>和ioptionsmonitor<>被注册为单例服务，而ioptionssnapshot<>被注册为范围服务。
由于ioptions<>和ioptionsmonitor<>都被注册为单例服务，因此每次获取的都是同一个实例，所以更改了以后的值是保留的。
而ioptionssnapshot<>被注册为范围服务，所以每次创建新范围时获取的都是一个新的值，外部的更改只对当次有效，不会保留到下次（不能跨范围，对于asp.net core来说不能跨请求）。

我们继续看第二次修改，第二次修改配置文件后ioptionsmonitor<>和ioptionssnapshot<>的值更新了，而ioptions<>的值没有更新。
ioptions<>好理解，它被注册为单例服务，第一次访问的时候生成实例并加载配置文件中的值，此后再也不会读取配置文件，所以它的值不会更新。
ioptionssnapshot<>被注册为范围服务，每次重新生成一个新的范围时，它都会从配置文件中获取值，因此它的值会更新。
但是，ioptionsmonitor<>呢，它被注册为单例，为什么也会更新呢？
让我们回到addoptions的源代码，我们留意到ioptionsmonitor<>的实现是optionsmanager<>。
当我们打开optionsmanager的源代码时，一切都很清楚了。
它的构造函数如下：

public optionsmonitor(ioptionsfactory<toptions> factory, ienumerable<ioptionschangetokensource<toptions>> sources, ioptionsmonitorcache<toptions> cache)
{
    _factory = factory;
    _sources = sources;
    _cache = cache;

    foreach (var source in _sources)
    {
        var registration = changetoken.onchange(
                () => source.getchangetoken(),
                (name) => invokechanged(name),
                source.name);

        _registrations.add(registration);
    }
}

原来optionsmonitor的更新能力是从ioptionschangetokensource<toptions>而来，但是这个接口的实例又是谁呢？
我们回到最开始的代码的第10行：

services.configure<testoptions>(configuration);

这是一个定义在microsoft.extensions.options.configurationextensions.dll的扩展方法，最后实际调用的是它的一个重载方法，代码如下：

 1 public static iservicecollection configure<toptions>(this iservicecollection services, string name, iconfiguration config, action<binderoptions> configurebinder)
 2     where toptions : class
 3 {
 4     if (services == null)
 5     {
 6         throw new argumentnullexception(nameof(services));
 7     }
 8 
 9     if (config == null)
10     {
11         throw new argumentnullexception(nameof(config));
12     }
13 
14     services.addoptions();
15     services.addsingleton<ioptionschangetokensource<toptions>>(new configurationchangetokensource<toptions>(name, config));
16     return services.addsingleton<iconfigureoptions<toptions>>(new namedconfigurefromconfigurationoptions<toptions>(name, config, configurebinder));
17 }

秘密就在上面的第15行，configurationchangetokensource，它引用了代表配置文件的对象config，所以配置文件更新，ioptionsmonitor就会跟着更新。

结论

ioptions<>是单例，因此一旦生成了，除非通过代码的方式更改，它的值是不会更新的。
ioptionsmonitor<>也是单例，但是它通过ioptionschangetokensource<> 能够和配置文件一起更新，也能通过代码的方式更改值。
ioptionssnapshot<>是范围，所以在配置文件更新的下一次访问，它的值会更新，但是它不能跨范围通过代码的方式更改值，只能在当前范围（请求）内有效。

官方文档是这样介绍的：
ioptionsmonitor<toptions>用于检索选项和管理toptions实例的选项通知，它支持下面的场景：

• 实例更新通知。
• 命名实例。
• 重新加载配置。
• 选择性的让实例失效。

ioptionssnapshot<toptions>在需要对每个请求重新计算选项的场景中非常有用。
ioptions<toptions>可以用来支持options模式，但是它不支持前面两者所支持的场景，如果你不需要支持上面的场景，你可以继续使用ioptions<toptions>。

所以你应该根据你的实际使用场景来选择到底是用这三者中的哪一个。
一般来说，如果你依赖配置文件，那么首先考虑ioptionsmonitor<>，如果不合适接着考虑ioptionssnapshot<>，最后考虑ioptions<>。
有一点需要注意，在asp.net core应用中ioptionsmonitor可能会导致同一个请求中选项的值不一致——当你正在修改配置文件的时候——这可能会引发一些奇怪的bug。
如果这个对你很重要，请使用ioptionssnapshot，它可以保证同一个请求中的一致性，但是它可能会带来轻微的性能上的损失。
如果你是在app启动的时候自己构造options（比如在startup类中）：

services.configure<testoptions>(opt => opt.name = "test 0");

ioptions<>最简单，也许是一个不错的选择，configure扩展方法还有其他重载可以满足你的更多需求。