ASP.NET Core引入了Options模式，使用類來表示相關的設置組。簡單的來說，就是用強類型的類來表達配置項，這帶來了很多好處。初學者會發現這個框架有3個主要的面向消費者的介面：IOptions ...

背景

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擴展方法還有其他重載可以滿足你的更多需求。

IOptions、IOptionsMonitor以及IOptionsSnapshot

背景

示例

分析

結論