【5min+】更好的选项实践。.Net Core中的IOptions

这样就完成了关注点的分离，我们不需要一直死守着Startup.cs文件不放，也不需要让用户手动去配置。只要我们知道IServiceCollection就可以往里面添加我们自己的业务点。当然，Microsoft.Extensions.Options包还提供了另外的方式让您可以完成IConfigureOptions的同样操作，不过这些操作都是像语法糖一样，实质上是相同的：

//和上面同样的功能
services.Configure(Options =>
{
     options.Filters.Add(new MyFileter());
});

IOptions、IOptionsMonitor和IOptionsSnapshot

在上面其实我们已经见过了IOptions的尊容，我们可以通过注入IOptions来获取MyOptions实例。

但是！但是！但是！！！！ IOptions还有两个兄弟IOptionsMonitor和IOptionsSnapshot。光名字上长的就很像了，它们都还有类似于“Value”的属性来获取选项实例。

妈呀，那么它们到底有什么不同呢？什么时候该用老大，什么使用该用老二呢？ 接下来，年度最佳找不同大戏即将开始………………

先来看看IOptions和IOptionsSnapshot吧，看看它们的接口定义：

/// 

/// Used to access the value of  for the lifetime of a request.
/// 
/// Options type.
public interface IOptionsSnapshotout TOptions> : IOptionsTOptions> where TOptions : class, new()
{
    /// 

    /// Returns a configured  instance with the given name.
    /// 
    TOptions Get(string name);
}

我天，居然IOptionsSnapshot还继承了IOptions，而且只是多了一个Get方法，那么是否这两个类其实很相似呢？我们直接来看看源码：

services.TryAdd(ServiceDescriptor.Singleton(typeof(IOptions), typeof(OptionsManager)));
services.TryAdd(ServiceDescriptor.Scoped(typeof(IOptionsSnapshot), typeof(OptionsManager)));

纳尼？这都还不是相似不相似的问题，这TM不是同一个实现吗？只是接口类型不同而已，实现都是OptionsManager。 那为啥要搞两个不同的接口。

等等（手动播放名侦探bgm），这俩生命周期咋不一样？ 一个是Singleton一个是Scoped。而再来看IOptionsSnapshot的说明：“Used to access the value of TOptions for the lifetime of a request.”（用于在请求的生存期内访问选项的值）。

原来如此，这样看来就很清晰了。它俩的区别其实就是依赖注入的生命周期不同而已，为单例的IOptions意味着，只要您注入之后以后获取的都是同一个实例，而IOptionsSnapshot呢，作为Scoped级别，每再一个新的Scoped中获取它一次，它就会请求一个新的实例。

所以来举个例子，在AspNet Core中咱们某个选项的值是根据一个文件的某个值来的。刚开始文本的值是“A”，咱们在运行AspNet Core之后我们获取IOptions和IOptionsSnapshot，此时得到的MyOptions的该属性的值都是"A"。但是假如我们更改了文本的值，改为“B”。如果在发起一个http请求去获取MyOptions的结果，此时IOptions依旧是“A”，而IOptionsSnapshot则更改为了B。

原因很简单，因为IOptions是单例的，所以从程序一开始加载过一次之后，以后访问它都是这个结果，而IOptionsSnapshot是Scoped级别的，所以每一个新的Scoped时都会又去访问文本文件获取值，而一次Http请求就会开启一次新的Scoped，所以此时结果就成为“B”。这个时候我们大概就能读懂上面IOptionsSnapshot接口的解释了：“用于在请求的生存期内访问选项的值”。

三兄弟一下就干掉了俩，接下来看看最后一个好兄弟（毒瘤）:IOptionsMonitor。还是直接看它的源代码呢：

services.TryAdd(ServiceDescriptor.Singleton(typeof(IOptionsMonitor), typeof(OptionsMonitor)));

纳尼？单例？ 那是不是意味着它也一样，一旦启动了之后还是保持原有的结果呢？先不急，看看它的接口定义再说：

/// 

/// Used for notifications when  instances change.
/// 
/// The options type.
public interface IOptionsMonitorout TOptions>
{
    /// 

    /// Returns the current  instance with the .
    /// 
    TOptions CurrentValue { get; }

    /// 

    /// Returns a configured  instance with the given name.
    /// 
    TOptions Get(string name);

    /// 

    /// Registers a listener to be called whenever a named  changes.
    /// 
    /// The action to be invoked when  has changed.
    /// An  which should be disposed to stop listening for changes.
    IDisposable OnChange(Actionstring> listener);
}

可以看出它自己是一个单独的接口，并不像其它俩兄弟是继承关系。而且该接口居然有一个OnChange签名？而且该方法需要一个Action的参数。

握草（继续手动播放名侦探bgm），如果您有幸看过我的上一篇文章：《【5min+】 一个令牌走天下！.Net Core中的ChangeToken》，那么您可能一下就知道它扮演了什么样的角色。(5min+系列居然是连续的.... ??)

再看看该接口的说明："Used for notifications when TOptions instances change."（用于在选项实例更改时进行通知）。果然和我们猜的一模一样，那么它的实现类里面一定有咱们上一篇文章中提到的：ChangeToken和IChangeToken等东西。

来吧，扒开它的具体实现，验证咱们的猜想：

 public OptionsMonitor(IOptionsFactory factory, IEnumerable> sources, IOptionsMonitorCache 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);
    }
}

意料之中，也就是说IOptionsMonitor的注入级别虽然是单例，但是因为它具有IChangeToken的实现，所以它能够在选项源改变的时候，“立马对选项做出对应的改变”。而改变依赖于IOptionsChangeTokenSource这个令牌源，目前.net core对很多常用工具都实现了该令牌源，比如Logger,Configuration等。所以当我们某个选项依赖于IConfiguration（appsetting.json）的某一项时，当修改appsetting.json文件，该选项的值就能够立马得到更改。

所以来回过头来看这三兄弟。它们的区别其实在于变更的时效性：

假如把IOptionsMonitor添加到上面IOptions和IOptionsSnapshot的文件变更案例，如果在一次HTTP请求中，文件变更了两次，那么IOptionsSnapshot不会在第二次更改中同步更改，而IOptionsMonitor则可以。

那么什么时候来使用什么样的接口呢？相信这个时候，您的心里比我还要清楚。当您的选项只是负责一次性处理的时候，应用启动了就不需要更改，那么考虑使用IOptions，如果是对数据源的变更要求很严格，比如开启了一个“BackgroundJob”在后台运行，该job需要一个选项类型，而该类型依赖于配置文件，需要对配置文件更改时即刻做出改变，那么请考虑使用IOptionsMonitor。

最后回过头来看微软官方文档上关于“Options”的两个点(ISP和关注点分离)，您应该一下就能理解。

如果您有兴趣的话可以跳转至官方文档进行阅读：《ASP.NET Core 中的选项模式》

好啦，今天的车就开完了，如果您喜欢该系列文章可以点击关注。??

最后，偷偷说一句：创作不易，点个推荐吧.....

【5min+】更好的选项实践。.Net Core中的IOptions

标签：img   spn   core   actor   red   filter   round   情况   碎片   

原文地址：https://www.cnblogs.com/lonelyxmas/p/12603318.html