背景

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

轉載請註明出處，本文鏈接：https://www.uj5u.com/net/52849.html

標籤：.NET Core

上一篇：基于.NetCore3.1系列 —— 使用Swagger做Api檔案 (下篇)

下一篇：NET Core 部署IIS 碰到得問題解決（內托管模式超時、不允許得請求謂詞、直接請求無回應、拒絕服務405）

IOptions、IOptionsMonitor以及IOptionsSnapshot

背景

示例

分析

結論