背景

ASP.NET Core引入了Options模式，使用類來表示相關(guān)的設(shè)置組。簡單的來說，就是用強類型的類來表達(dá)配置項，這帶來了很多好處。
初學(xué)者會發(fā)現(xiàn)這個框架有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); //注意最后一個參數(shù)值，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框架的源代碼著手，理解為什么會這樣。
當(dāng)我們需要使用Options模式時，我們都會調(diào)用定義在OptionsServiceCollectionExtensions類上的擴展方法AddOptions(this IServiceCollection services)。

var services = new ServiceCollection();
services.AddOptions();

我們觀察AddOptions方法的實現(xiàn)：

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<>被注冊為單例服務(wù)，而IOptionsSnapshot<>被注冊為范圍服務(wù)。
由于IOptions<>和IOptionsMonitor<>都被注冊為單例服務(wù)，因此每次獲取的都是同一個實例，所以更改了以后的值是保留的。
而IOptionsSnapshot<>被注冊為范圍服務(wù)，所以每次創(chuàng)建新范圍時獲取的都是一個新的值，外部的更改只對當(dāng)次有效，不會保留到下次（不能跨范圍，對于ASP.NET Core來說不能跨請求）。

我們繼續(xù)看第二次修改，第二次修改配置文件后IOptionsMonitor<>和IOptionsSnapshot<>的值更新了，而IOptions<>的值沒有更新。
IOptions<>好理解，它被注冊為單例服務(wù)，第一次訪問的時候生成實例并加載配置文件中的值，此后再也不會讀取配置文件，所以它的值不會更新。
IOptionsSnapshot<>被注冊為范圍服務(wù)，每次重新生成一個新的范圍時，它都會從配置文件中獲取值，因此它的值會更新。
但是，IOptionsMonitor<>呢，它被注冊為單例，為什么也會更新呢？
讓我們回到AddOptions的源代碼，我們留意到IOptionsMonitor<>的實現(xiàn)是OptionsManager<>。
當(dāng)我們打開OptionsManager的源代碼時，一切都很清楚了。
它的構(gòu)造函數(shù)如下：

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的擴展方法，最后實際調(diào)用的是它的一個重載方法，代碼如下：

 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就會跟著更新。

結(jié)論

IOptions<>是單例，因此一旦生成了，除非通過代碼的方式更改，它的值是不會更新的。
IOptionsMonitor<>也是單例，但是它通過IOptionsChangeTokenSource<> 能夠和配置文件一起更新，也能通過代碼的方式更改值。
IOptionsSnapshot<>是范圍，所以在配置文件更新的下一次訪問，它的值會更新，但是它不能跨范圍通過代碼的方式更改值，只能在當(dāng)前范圍（請求）內(nèi)有效。

官方文檔是這樣介紹的：
IOptionsMonitor<TOptions>用于檢索選項和管理TOptions實例的選項通知，它支持下面的場景：

實例更新通知。
命名實例。
重新加載配置。
選擇性的讓實例失效。

IOptionsSnapshot<TOptions>在需要對每個請求重新計算選項的場景中非常有用。
IOptions<TOptions>可以用來支持Options模式，但是它不支持前面兩者所支持的場景，如果你不需要支持上面的場景，你可以繼續(xù)使用IOptions<TOptions>。

所以你應(yīng)該根據(jù)你的實際使用場景來選擇到底是用這三者中的哪一個。
一般來說，如果你依賴配置文件，那么首先考慮IOptionsMonitor<>，如果不合適接著考慮IOptionsSnapshot<>，最后考慮IOptions<>。
有一點需要注意，在ASP.NET Core應(yīng)用中IOptionsMonitor可能會導(dǎo)致同一個請求中選項的值不一致——當(dāng)你正在修改配置文件的時候——這可能會引發(fā)一些奇怪的bug。
如果這個對你很重要，請使用IOptionsSnapshot，它可以保證同一個請求中的一致性，但是它可能會帶來輕微的性能上的損失。
如果你是在app啟動的時候自己構(gòu)造Options（比如在Startup類中）：

services.Configure<TestOptions>(opt => opt.Name = "Test 0");

IOptions<>最簡單，也許是一個不錯的選擇，Configure擴展方法還有其他重載可以滿足你的更多需求。

本站僅提供存儲服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請點擊舉報。

免费视频淫片aa毛片_日韩高清在线亚洲专区vr_日韩大片免费观看视频播放_亚洲欧美国产精品完整版

背景

示例

分析

結(jié)論