.net core的配置介绍（三）：Options

　　前两篇介绍的都是已IConfiguration为基础的配置，这里在说说.net core提供的一种全新的辅助配置机制：Options。

　　Options，翻译成中文就是选项，可选择的意思，它依赖于.net core提供的DI机制（DI机制以后再说），Options的对象是具有空构造函数的类。

　　Options是一个独立的拓展库，它不像IConfiguration那样可以从外部文件获取配置，它其实可以理解为一种代码层面的配置，.net core内部大量的实现类采用了IOptions机制，基本上，.net core中任何一个依赖DI存在的库，或多或少都会有Options的影子，比如日志的LoggerFilterOptions，认证授权的AuthenticationOptions等等，

　　

　　一、原理

　　想了一下，这里原理的介绍可以分成两个部分：配置和读取

　　配置

　　Options的配置一般采用IServiceCollection的Configure，ConfigureAll，PostConfigure，PostConfigureAll，ConfigureOptions和带泛型参数的AddOptions<TOptions>等拓展方法以及他们的重载来实现，同时，Options可以指定一个名称，用来区分同一类型的Options，如果不指定名称，那么默认将采用Options.DefaultName（源码）作为名称，其实也就是空字符串（不是null，当名称是null时代表全部，后面介绍）。其实这几个方法的本质就是往DI容器中注册IConfigureOptions<TOptions>（源码）或者IPostConfigureOptions<TOptions>（源码）接口的服务，只不过注册进去的类或者名称不一样而已，可以查看源码（源码）。

　　Configure和ConfigureAll

　　Configure和ConfigureAll是最主要的配置入口，对同一个类型可以多次进行配置，其中，Configure是对指定名称的Options进行配置，而ConfigureAll是对同一类型的所有Options进行配置，其实ConfigureAll(action)等价于Configure(null,action)，这里是前面说的Options的默认名称不是null，而是空字符串（源码）：　　

    public static IServiceCollection ConfigureAll<TOptions>(this IServiceCollection services, Action<TOptions> configureOptions) where TOptions : class
           => services.Configure(name: null, configureOptions: configureOptions);

　　所以我们只需要关注Configure方法就可以了，Configure注册的服务是ConfigureNamedOptions<TOptions>（源码），它实现了IConfigureNamedOptions<TOptions>接口，而IConfigureNamedOptions<TOptions>接口是IConfigureOptions<TOptions>接口的一个子接口，接口实现内容如下（源码）：　　

　　 // IConfigureNamedOptions<TOptions>接口实现
    public virtual void Configure(string name, TOptions options)
    {
        if (options == null)
        {
            throw new ArgumentNullException(nameof(options));
        }

        // Null name is used to configure all named options.
        if (Name == null || name == Name)
        {
            Action?.Invoke(options);
        }
    }

    public void Configure(TOptions options) => Configure(Options.DefaultName, options);// IConfigureOptions<TOptions>接口实现

　　从实现方法也可以看到，当Options的名称为null时，表示对所有此类型的Options均进行配置。

　　总之，我们只需要记住，Configure和ConfigureAll方法只是往DI中对IConfigureOptions<TOptions>接口注册ConfigureNamedOptions<TOptions>服务，只不过ConfigureAll注册的名称是null，Configure注册的名称默认是Options.DefaultName。

　　PostConfigure和PostConfigureAll

　　有了Configure和ConfigureAll，为什么还要有PostConfigure和PostConfigureAll？举个例子，我们要组装车子，Configure1配置好了轮子，Configure2配置好了车架，Configure3配置好了内饰，那组装要等这三个配置好了才能组装吧，这也就是PostConfigure的由来。

　　和ConfigureAll一样，PostConfigureAll与PostConfigure的区别就是PostConfigureAll使用的name是null（源码）：　　

    public static IServiceCollection PostConfigureAll<TOptions>(this IServiceCollection services, Action<TOptions> configureOptions) where TOptions : class
         => services.PostConfigure(name: null, configureOptions: configureOptions);

　　所以，我们也只需要关注PostConfigure方法就可以了，而PostConfigure方法注册的服务是PostConfigureOptions<TOptions>（源码），它实现的是IPostConfigureOptions<TOptions>接口（源码）：　　

    public virtual void PostConfigure(string name, TOptions options)
    {
        if (options == null)
        {
            throw new ArgumentNullException(nameof(options));
        }

        // Null name is used to initialize all named options.
        if (Name == null || name == Name)
        {
            Action?.Invoke(options);
        }
    }

　　实现内容几乎和ConfigureNamedOptions<TOptions>是一样的，总之，只需要记住，PostConfigure和PostConfigureAll方法只是往DI中对IPostConfigureOptions<TOptions>接口注册PostConfigureOptions<TOptions>服务，只不过PostConfigureAll注册的名称是null，PostConfigure注册的名称默认是Options.DefaultName。

　　ConfigureOptions

　　前面说到，无论是Configure还是PostConfigure，都是往DI容器中注册IConfigureOptions<TOptions>和IPostConfigureOptions<TOptions>的服务，但是他们配置的载体是委托Action，因此，ConfigureOptions方法允许我们自己以类的形式作为载体去进行配置，只不过需要我们自己去实现IConfigureOptions<TOptions>或IPostConfigureOptions<TOptions>接口，或者我们也可以使用默认实现好了的几个Options：ConfigureOptions<TOptions>、ConfigureNamedOptions<TOptions>和PostConfigureOptions<TOptions>，如果自己实现，比如有实现类：　　

    public class TestConfigureOptions : IConfigureOptions<TestOptions>, IPostConfigureOptions<TestOptions>
    {
        public void Configure(TestOptions options)
        {
            //配置
        }

        public void PostConfigure(string name, TestOptions options)
        {
            //配置
        }
    }
    public class TestOptions
    {
        //属性
    }

　　然后可以使用ConfigureOptions方法配置了：　　

    public void ConfigureServices(IServiceCollection services)
    {
        services.ConfigureOptions<TestConfigureOptions>();
        ...
    }

　　AddOptions<TOptions>

　　带泛型的AddOptions<TOptions>方法返回一个OptionsBuilder<TOptions>方法（源码），它则可进行更多的配置，比如上面Configure和PostConfigure方法的功能，但是OptionsBuilder<TOptions>只是配置包含名称的Options，默认名称就是Options.DefaultName，也就是说OptionsBuilder<TOptions>无法配置像ConfigureAll和PostConfigureAll那样的功能。

　　OptionsBuilder<TOptions>除了包含Configure和PostConfigure方法的功能，主要还有几个功能：

　　1、OptionsBuilder<TOptions>允许我们从DI中获取服务或者其他配置来进行操作进一步的配置，比如我们有下面的Options：　　

    public class VarOptions
    {
        public int Var { get; set; }
    }
    public class SumOptions
    {
        public int Sum { get; set; }
    }
    public class MultipleOptions
    {
        public int Multiple { get; set; }
    }

　　然后我们使用配置：　　

    public void ConfigureServices(IServiceCollection services)
    {
        services.Configure<VarOptions>("Var1", options =>
        {
            options.Var = 1;
        });
        services.Configure<VarOptions>("Var2", options =>
        {
            options.Var = 2;
        });
        services.AddOptions<SumOptions>().Configure<IOptionsFactory<VarOptions>>((options, factory) =>
        {
            var varOption1 = factory.Create("Var1");
            var varOption2 = factory.Create("Var2");
            options.Sum = varOption1.Var + varOption2.Var;
        });
        services.AddOptions<MultipleOptions>().Configure<IOptionsFactory<VarOptions>>((options, factory) =>
        {
            var varOption1 = factory.Create("Var1");
            var varOption2 = factory.Create("Var2");
            options.Multiple = varOption1.Var * varOption2.Var;
        });
        ...
    }

　　可以看到，VarOptions有两个名称：Var1和Var2，我们的SumOptions和MultipleOptions的配置是从DI中获取VarOptions的配置来生成的。

　　注意的是，OptionsBuilder<TOptions>的Configure和PostConfigure方法往DI中注册的服务也不一样，除了ConfigureNamedOptions<TOptions>和PostConfigureOptions<TOptions>，还会有很多ConfigureNamedOptions<TOptions,TDep1,TDep2...>和PostConfigureOptions<TOptions,TDep1,TDep2...>这样的服务实现类。

　　2、OptionsBuilder<TOptions>提供了Validate方法及它的重载，允许我们配置完Options后，可以自定义的对Options进行验证，比如上面我们将SumOptions增加验证，要求相加后的值要大于10：　　

    services.AddOptions<SumOptions>().Configure<IOptionsFactory<VarOptions>>((options, factory) =>
    {
        var varOption1 = factory.Create("Var1");
        var varOption2 = factory.Create("Var2");
        options.Sum = varOption1.Var + varOption2.Var;
    }).Validate(options => options.Sum > 10);

　　这样，当配置完SumOptions之后，在验证时，发现它的Sum属性不大于10，那么就会抛出异常了。

　　注意，这个验证是在获取配置使用的时候进行的

　　本质上，OptionsBuilder<TOptions>的Validate方法其实是往DI中注册IValidateOptions<TOptions>接口的服务：ValidateOptions<TOptions>和很多ValidateOptions<TOptions,TDep1,TDep2...>。

　　3、OptionsBuilder<TOptions>可以给Options增加特性验证，熟悉EF的朋友肯定都知道，我们可以是实体的属性增加一些特性，比如RequiredAttribute，MaxLengthAttribute等，然后EF就是自动帮我们进行验证了，同样的，我们也可以对Options使用这些特性，比如，我们有下面的一个Options：　　

    public class TestOptions
    {
        [Required, MaxLength(5)]
        public string Value { get; set; }
    }

　　然后做下面的配置：　　

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddOptions<TestOptions>("Test1").Configure(options =>
        {
            options.Value = null;
        }).ValidateDataAnnotations();
        services.AddOptions<TestOptions>("Test2").Configure(options =>
       {
           options.Value = "1234567890";
       }).ValidateDataAnnotations();
        services.AddOptions<TestOptions>("Test3").Configure(options =>
       {
           options.Value = "abc";
       }).ValidateDataAnnotations();
        ...
    }

　　当我们获取名称是Test1的Options是会因为Required特性报错，当我们获取名称是Test2的Options时，会因为MaxLength(5)报错，而Test3是正确的。

　　另外，可以看到，这里验证只是使用了ValidateDataAnnotations方法（源码），其实它只是Options验证的一个拓展，它只不过是使用了DataAnnotationValidateOptions<TOptions>（源码）来做验证，而DataAnnotationValidateOptions<TOptions>就是实现了 IValidateOptions<TOptions>接口的一个类：　　

    public static OptionsBuilder<TOptions> ValidateDataAnnotations<TOptions>(this OptionsBuilder<TOptions> optionsBuilder) where TOptions : class
    {
        optionsBuilder.Services.AddSingleton<IValidateOptions<TOptions>>(new DataAnnotationValidateOptions<TOptions>(optionsBuilder.Name));
        return optionsBuilder;
    }

　　读取

　　Options的配置说完了，再看看读取。

　　无论是在配置的Configure，PostConfigure，还是ConfigureOptins，AddOptions<TOptions>方法，都是执行一个不带泛型参数的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;
    }

　　可以看到，这个方法就是注册5个类，它们就和Options读取有关，我们可以在服务（比如控制器）的构造函数中注入Options，比如：　　

    [ApiController]
    [Route("[controller]")]
    public class HomeController : ControllerBase
    {
        public HomeController(IOptions<TestOptions> options,
            IOptionsFactory<TestOptions> optionsFactory,
            IOptionsMonitor<TestOptions> optionsMonitor,
            IOptionsSnapshot<TestOptions> optionsSnapshot,
            IOptionsMonitorCache<TestOptions> optionsMonitorCache)
        {
            var options1 = options.Value;
            var options2 = optionsFactory.Create(Options.DefaultName);
            var options3 = optionsMonitor.CurrentValue;//或者使用optionsMonitor.Get(name)
            var options4 = optionsSnapshot.Get(Options.DefaultName);
            var options5 = optionsMonitorCache.GetOrAdd(Options.DefaultName, () => new TestOptions());
        }
        ...
    }

　　但是这五种方式的表现不一样：　　

    IOptions<TOptions>：全局缓存配置（Singleton），也就是说Configure和PostConfigure等方法的配置内容只会被执行一遍，然后全局使用这一个配置
    IOptionsSnapshot<TOptions>：范围内的配置（Scoped，这个以后DI中说，暂时可以认为一个http请求响应就是一个Scoped），也就是说一个Scoped范围内，Configure和PostConfigure等方法的配置内容只会被执行一遍
    IOptionsMonitor<TOptions>：全局可监听的配置（Singleton），首先从IOptionsMonitorCache<TOptions>缓存加载，没有加载到则使用IOptionsFactory<TOptions>创建，同时我们可以注册IOptionsChangeTokenSource<TOptions>来进行监听，决定何时清除缓存然后重新创建Options
    IOptionsFactory<TOptions>：Options的创建工厂（Singleton）,他没有缓存，直接创建Options，这样从某种层面来说有性能的损失。
    IOptionsMonitorCache<TOptions>：IOptionsMonitor<TOptions>的缓存（Singleton），如果需要，我们可以直接从DI中获取缓存操作，来决定IOptionsMonitor<TOptions>接下来是从缓存中获取Options还是使用IOptionsFactory<TOptions>创建

　　另外它们的实现类也有区别：

　　1、IOptions<TOptions>和IOptionsSnapshot<TOptions>都是采用OptionsManager<TOptions>（源码），它的源码很简单，实际上就是从DI中获取IOptionsFactory<TOptions>工厂来创建Options

　　2、IOptionsMonitorCache<TOptions>的服务类是OptionsCache<TOptions>（源码），它其实就是管理Options集合的类，比如增加，移除，清空等等。

　　3、IOptionsFactory<TOptions>的服务类是OptionsFactory<TOptions>（源码），它从DI中获取TOptions的所有IConfigureOptions<TOptions>、IPostConfigureOptions<TOptions>和 IValidateOptions<TOptions>的服务类，可以看看它的Create方法（源码）：　　

    public TOptions Create(string name)
    {
        var options = new TOptions();
        foreach (var setup in _setups)
        {
            if (setup is IConfigureNamedOptions<TOptions> namedSetup)
            {
                namedSetup.Configure(name, options);
            }
            else if (name == Options.DefaultName)
            {
                setup.Configure(options);
            }
        }
        foreach (var post in _postConfigures)
        {
            post.PostConfigure(name, options);
        }

        if (_validations != null)
        {
            var failures = new List<string>();
            foreach (var validate in _validations)
            {
                var result = validate.Validate(name, options);
                if (result.Failed)
                {
                    failures.AddRange(result.Failures);
                }
            }
            if (failures.Count > 0)
            {
                throw new OptionsValidationException(name, typeof(TOptions), failures);
            }
        }

        return options;
    }

　　现在，上面不断介绍的往DI中注册的IConfigureOptions<TOptions>、IPostConfigureOptions<TOptions>和 IValidateOptions<TOptions>知道在哪里用，怎么用的了吧。

　　4、IOptionsMonitor<TOptions>的服务类是OptionsMonitor<TOptions>，它注入IOptionsFactory<TOptions>，IOptionsMonitorCache<TOptions>，还有所有的IOptionsChangeTokenSource<TOptions>，它会优先从IOptionsMonitorCache<TOptions>缓存中获取Options，如果缓存没有，则使用IOptionsFactory<TOptions>创建并放入缓存中，而IOptionsChangeTokenSource<TOptions>是IOptionsMonitor<TOptions>的监听机制，它决定了IOptionsMonitorCache<TOptions>何时刷新，从而可以让IOptionsFactory<TOptions>去创建。

　　

　　二、Options和IConfiguration

　　Options和IConfiguration是可以结合使用的，IConfiguration从外部读取配置，然后使用Options将配置读取到我们熟悉的实体中使用，还可以和IConfiguration的重新加载机制结合。

　　.net core中通过拓展IServiceCollection的Configure方法（源码）和OptionsBuilder<TOptions>的Bind方法（源码）来集合IConfiguration，不过最终都是同下面的Configure方法进行注册（源码）：

    public static IServiceCollection Configure<TOptions>(this IServiceCollection services, string name, IConfiguration config, Action<BinderOptions> configureBinder)
        where TOptions : class
    {
        if (services == null)
        {
            throw new ArgumentNullException(nameof(services));
        }

        if (config == null)
        {
            throw new ArgumentNullException(nameof(config));
        }

        services.AddOptions();
        services.AddSingleton<IOptionsChangeTokenSource<TOptions>>(new ConfigurationChangeTokenSource<TOptions>(name, config));
        return services.AddSingleton<IConfigureOptions<TOptions>>(new NamedConfigureFromConfigurationOptions<TOptions>(name, config, configureBinder));
    }

　　可以看到，它注册的是IConfigureOptions<TOptions>接口的NamedConfigureFromConfigurationOptions<TOptions>（源码）服务，而NamedConfigureFromConfigurationOptions<TOptions>只是ConfigureNamedOptions<TOptions>的一个子类，只不过NamedConfigureFromConfigurationOptions<TOptions>中是将IConfiguration中的配置值通过它的Bind拓展方法绑定到实体Options上。

　　另外，这里面还注册了IOptionsChangeTokenSource<TOptions>的服务ConfigurationChangeTokenSource<TOptions>（源码），它的作用就是将Options的监听与IConfiguration的重新加载机制结合起来。

　　在使用时，举个例子，比如appsettings.json有如下配置

  {
    ...
    "Data": {
      "Value1": 1,
      "Value2": 3.14,
      "Value3": true,
      "Value4": [ 1, 2, 3 ],
      "Value5": {
        "Value1": 2,
        "Value2": 5.20,
        "Value3": false,
        "Value4": [ 4,5,6,7 ]
      }
    }
  }

　　然后我们有一个对应的ptions

    public class DataOptions
    {
        public int Value1 { get; set; }
        public decimal Value2 { get; set; }
        public bool Value3 { get; set; }
        public int[] Value4 { get; set; }
        public DataOptions Value5 { get; set; }
    }

　　然后只需要结合IConfiguration和Options注册即可：　　

    public void ConfigureServices(IServiceCollection services)
    {
        services.Configure<DataOptions>(Configuration.GetSection("Data"));
        ...
    }

　　接下来就可以直接以Options的方式读取配置了

　　

　　三、Options使用例子

　　下面例子的Demo已上传：https://pan.baidu.com/s/10mU79U6YYCj4-yQies6zRQ （提取码: yywq ）

　　更多集成使用的Demo可以参考这里我封装实现的.net core对RabbitMQ，ActiveMQ，Kafka等操作的Demo：https://gitee.com/shanfeng1000/dotnetcore-demo

　　不带名称的Options

　　不带名称的Options常用于一些全局的配置，比如MvcOptions，或者一些创建工厂的配置Options，也就是说往往我们的DI中只存在一个服务类或者不用区分服务类的时候，往往使用的是不带名称的Options。

　　举个例子，比如我们有下面的连接工厂类及连接类：

　　

    public interface IConnectionFactory
    {
        /// <summary>
        /// 创建连接
        /// </summary>
        /// <returns></returns>
        IConnection Create();
    }
    public class ConnectionFactory : IConnectionFactory
    {
        IOptionsMonitor<ConnectionFactoryOptions> optionsMonitor;
        public ConnectionFactory(IOptionsMonitor<ConnectionFactoryOptions> optionsMonitor)
        {
            this.optionsMonitor = optionsMonitor;
        }

        /// <summary>
        /// 创建连接
        /// </summary>
        /// <returns></returns>
        public IConnection Create()
        {
            return new Connection(optionsMonitor.CurrentValue.ConnectionString);
        }
    }
    public class ConnectionFactoryOptions
    {
        /// <summary>
        /// 连接字符串
        /// </summary>
        public string ConnectionString { get; set; }
    }
    public interface IConnection
    {
        /// <summary>
        /// 打开连接
        /// </summary>
        void Open();
        /// <summary>
        /// 关闭连接
        /// </summary>
        void Close();
    }
    public class Connection : IConnection
    {
        string connectionString;
        public Connection(string connectionString)
        {
            this.connectionString = connectionString;
        }

        /// <summary>
        /// 打开连接
        /// </summary>
        public void Open()
        {
            Console.WriteLine("Connecting:" + connectionString);
            Console.WriteLine("Connection Opened!");
        }
        /// <summary>
        /// 关闭连接
        /// </summary>
        public void Close()
        {
            Console.WriteLine("Disconnecting:" + connectionString);
            Console.WriteLine("Connection Closed!");
        }
    }

　　注意到，我们.net core推荐面向接口开发，所以这里推荐使用了IConnectionFactory和IConnection接口。

　　另一方面，这些类的服务注册我们可以直接写在Startup中，但是推荐拓展方法做一层封装，然后在Startup中使用services.AddXXXXX()的形式注册，比如这里我们实现拓展类：　　

    public static class ConnectionFactoryExtensions
    {
        /// <summary>
        /// 添加连接
        /// </summary>
        /// <param name="services"></param>
        /// <param name="configuration"></param>
        /// <returns></returns>
        public static IServiceCollection AddConnectionFactory(this IServiceCollection services, IConfiguration configuration)
        {
            if (configuration == null) throw new ArgumentNullException(nameof(configuration));

            services.Configure<ConnectionFactoryOptions>(configuration);
            services.TryAddSingleton<IConnectionFactory, ConnectionFactory>();
            return services;
        }
    }

　　注意到，这里一般使用TryAddSingleton而不是AddSingleton，这样可以避免重复注册服务，而且，当我们注册不带名称的Options时，优先考虑使用IConfiguration，如果我们的Options数据不是来自IConfiguration，则可使用Action<TOptions>来实现。

　　假如我们在appsettings.json中有如下配置：　　

  {
    ...
    "ConnectionFactoryOptions": {
      "ConnectionString": "Oracle ConnectionString"
    }
  }

　　然后我们可以在Startup中这么写：　　

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddConnectionFactory(Configuration.GetSection("ConnectionFactoryOptions"));
        ...
    }

　　我们可以使用WebApi的接口Action做个Demo:　　

    /// <summary>
    /// 不带名称的Connectin工厂测试
    /// </summary>
    /// <returns></returns>
    [HttpGet("Connection")]
    public object Connection()
    {
        var factory = HttpContext.RequestServices.GetService<IConnectionFactory>();
        var connection = factory.Create();
        connection.Open();

        //do something...
        Thread.Sleep(1000);

        connection.Close();

        return "success";
    }

　　运行项目，然后调用接口，就可以看到控制台输出：

　　

　　保持项目处于运行状态，我们可以修改appsettings.json：

  {
    ...
    "ConnectionFactoryOptions": {
      "ConnectionString": "Mysql ConnectionString"
    }
  }

　　然后重新调用接口，你会发现Options重新加载了，其实这本质就是IConfiguration重新加载了：

　　

　　带名称的Options

　　有时候，我们往DI中注册的同一类型服务使用Options可能不一样，这种情况多数表现在Client模式下，这个时候就可以采用名称作为区分，比如.netcore 提供的AddAuthentication认证服务注册方法，可以注册多种认证方式，它们使用不同的名称做区分，不同名称的认证方式使用不同的配置，当我们要使用某个名称的认证时，一般只需要在Action中使用AuthorizeAttribute特性修饰，同时制定使用的认证名称即可。

　　举个例子，比如我们有以下的Client和它的工厂：　　

　　

    public interface IClientFactory
    {
        /// <summary>
        /// 创建Client
        /// </summary>
        /// <param name="name"></param>
        /// <returns></returns>
        IClient Create(string name);
    }
    public class ClientFactory : IClientFactory
    {
        IOptionsMonitor<ClientOptions> optionsMonitor;
        public ClientFactory(IOptionsMonitor<ClientOptions> optionsMonitor)
        {
            this.optionsMonitor = optionsMonitor;
        }

        /// <summary>
        /// 创建Client
        /// </summary>
        /// <param name="name"></param>
        /// <returns></returns>
        public IClient Create(string name)
        {
            ClientOptions clientOptions = optionsMonitor.Get(name);
            return new Client(name, clientOptions);
        }
    }
    public class ClientOptions
    {
        /// <summary>
        /// 时间
        /// </summary>
        public DateTime Time { get; set; }
    }
    public interface IClient
    {
        /// <summary>
        /// Do something
        /// </summary>
        void Invoke();
    }
    public class Client : IClient
    {
        ClientOptions clientOptions;
        string name;
        public Client(string name, ClientOptions clientOptions)
        {
            this.name = name;
            this.clientOptions = clientOptions;
        }

        /// <summary>
        /// Do something
        /// </summary>
        public void Invoke()
        {
            Console.WriteLine($"{name}.Time:{clientOptions.Time:yyyy-MM-dd HH:mm:ss}");
        }
    }

　　同样的，这里推荐使用面向接口开发，Startup中的注册推荐使用拓展方法封装：　　

　　

    public static class ClientFactoryExtensions
    {
        /// <summary>
        /// 添加Client
        /// </summary>
        /// <param name="services"></param>
        /// <param name="configure"></param>
        /// <returns></returns>
        public static IServiceCollection AddClientFactory(this IServiceCollection services, Action<ClientOptions> configure)
            => services.AddClientFactory(Options.DefaultName, configure);
        /// <summary>
        /// 添加Client
        /// </summary>
        /// <param name="services"></param>
        /// <param name="name"></param>
        /// <param name="configure"></param>
        /// <returns></returns>
        public static IServiceCollection AddClientFactory(this IServiceCollection services, string name, Action<ClientOptions> configure)
        {
            if (configure == null) throw new ArgumentNullException(nameof(configure));

            services.Configure(name, configure);
            services.TryAddSingleton<IClientFactory, ClientFactory>();
            return services;
        }
    }

　　往往，我们的Client配置不是从配置IConfiguration中读取的，所以一般使用Action<TOptions>作为配置载体，然后在Startup中使用：

    public void ConfigureServices(IServiceCollection services)
    {        
        services.AddClientFactory("Client1", options =>
        {
            options.Time = DateTime.Now;
        });
        services.AddClientFactory("Client2", options =>
        {
            options.Time = DateTime.Now;
        });
        ...
    }

　　同样的，我们可以使用WebApi接口来说明使用方法：

     /// <summary>
     /// 带名称的Client工厂测试
     /// </summary>
     /// <param name="name"></param>
     /// <returns></returns>
     [HttpGet("Client")]
     public object Client(string name)
     {
         var factory = HttpContext.RequestServices.GetService<IClientFactory>();
         var client = factory.Create(name);
         client.Invoke();
         return "success";
     }
     /// <summary>
     /// 删除IOptionsMonitorCache中的缓存，可以触发重新创建Options
     /// </summary>
     /// <param name="name"></param>
     /// <returns></returns>
     [HttpGet("Refresh")]
     public object Refresh(string name)
     {
         var cache = HttpContext.RequestServices.GetService<IOptionsMonitorCache<ClientOptions>>();
         cache.TryRemove(name);
         Console.WriteLine("Refresh");
         return "success";
     }

　　运行起来后调用Client接口，控制台会输出：

　　

　　因为我们使用的是IOptionsMonitor<TOptions>，它是有缓存存在的，因此每次创建的Options都是一样的，我们可以使用IOptionsMonitorCache<TOptions>来删除缓存，比如上面的Refresh接口：

　　

　　前面说到，除了使用IOptionsMonitorCache<TOptions>来删除缓存，还可以同过注册IOptionsChangeTokenSource<TOptions>接口的服务来实现，比如这里我们可以添加它的一个通用实现类和拓展方法：　　

　　

    public interface ICommonOptionsChangeTokenSource
    {
        /// <summary>
        /// 触发
        /// </summary>
        void Change();
    }
    public class CommonOptionsChangeTokenSource<TOptions> : IOptionsChangeTokenSource<TOptions>, ICommonOptionsChangeTokenSource
    {
        CancellationTokenSource cancellationTokenSource;
        CancellationChangeToken cancellationChangeToken;

        public CommonOptionsChangeTokenSource(string name)
        {
            Name = name ?? Options.DefaultName;
            cancellationTokenSource = new CancellationTokenSource();
            cancellationChangeToken = new CancellationChangeToken(cancellationTokenSource.Token);
        }

        public string Name { get; }

        public IChangeToken GetChangeToken()
        {
            return cancellationChangeToken;
        }
        public void Change()
        {
            var _cancellationTokenSource = new CancellationTokenSource();
            Interlocked.Exchange(ref cancellationChangeToken, new CancellationChangeToken(_cancellationTokenSource.Token));
            Interlocked.Exchange(ref cancellationTokenSource, _cancellationTokenSource).Cancel();
        }
    }

　　

    public static class CommonOptionsChangeTokenSourceExtensions
    {
        /// <summary>
        /// 添加IOptionsChangeTokenSource
        /// </summary>
        /// <typeparam name="TOptions"></typeparam>
        /// <param name="services"></param>
        /// <param name="action"></param>
        /// <returns></returns>
        public static IServiceCollection AddOptionsChangeTokenSource<TOptions>(this IServiceCollection services, Action<IServiceProvider, ICommonOptionsChangeTokenSource> action)
            => services.AddOptionsChangeTokenSource<TOptions>(Options.DefaultName, action);
        /// <summary>
        /// 添加IOptionsChangeTokenSource
        /// </summary>
        /// <typeparam name="TOptions"></typeparam>
        /// <param name="services"></param>
        /// <param name="name"></param>
        /// <param name="action"></param>
        /// <returns></returns>
        public static IServiceCollection AddOptionsChangeTokenSource<TOptions>(this IServiceCollection services, string name, Action<IServiceProvider, ICommonOptionsChangeTokenSource> action)
        {
            if (action == null) throw new ArgumentNullException(nameof(action));

            return services.AddSingleton<IOptionsChangeTokenSource<TOptions>>(serviceProvider =>
            {
                var source = new CommonOptionsChangeTokenSource<TOptions>(name);
                action?.Invoke(serviceProvider, source);
                return source;
            });
        }
        /// <summary>
        /// 添加IOptionsChangeTokenSource
        /// </summary>
        /// <typeparam name="TOptions"></typeparam>
        /// <param name="builder"></param>
        /// <param name="action"></param>
        /// <returns></returns>
        public static OptionsBuilder<TOptions> AddOptionsChangeTokenSource<TOptions>(this OptionsBuilder<TOptions> builder, Action<IServiceProvider, ICommonOptionsChangeTokenSource> action)
            where TOptions : class
        {
            builder.Services.AddOptionsChangeTokenSource<TOptions>(builder.Name, action);
            return builder;
        }
        /// <summary>
        /// 添加IOptionsChangeTokenSource
        /// </summary>
        /// <typeparam name="TOptions"></typeparam>
        /// <param name="services"></param>
        /// <param name="action"></param>
        /// <returns></returns>
        public static IServiceCollection AddOptionsChangeTokenSource<TOptions>(this IServiceCollection services, Action<ICommonOptionsChangeTokenSource> action)
            => services.AddOptionsChangeTokenSource<TOptions>(Options.DefaultName, action);
        /// <summary>
        /// 添加IOptionsChangeTokenSource
        /// </summary>
        /// <typeparam name="TOptions"></typeparam>
        /// <param name="services"></param>
        /// <param name="name"></param>
        /// <param name="action"></param>
        /// <returns></returns>
        public static IServiceCollection AddOptionsChangeTokenSource<TOptions>(this IServiceCollection services, string name, Action<ICommonOptionsChangeTokenSource> action)
        {
            if (action == null) throw new ArgumentNullException(nameof(action));
            var source = new CommonOptionsChangeTokenSource<TOptions>(name);
            action?.Invoke(source);
            return services.AddSingleton<IOptionsChangeTokenSource<TOptions>>(source);
        }
        /// <summary>
        /// 添加IOptionsChangeTokenSource
        /// </summary>
        /// <typeparam name="TOptions"></typeparam>
        /// <param name="builder"></param>
        /// <param name="action"></param>
        /// <returns></returns>
        public static OptionsBuilder<TOptions> AddOptionsChangeTokenSource<TOptions>(this OptionsBuilder<TOptions> builder, Action<ICommonOptionsChangeTokenSource> action)
            where TOptions : class
        {
            builder.Services.AddOptionsChangeTokenSource<TOptions>(builder.Name, action);
            return builder;
        }
    }

　　然后在Startup中使用：

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddOptionsChangeTokenSource<ClientOptions>("Client1", source =>
        {
            //使用定时器来模拟触发重新创建Options
            System.Timers.Timer timer = new System.Timers.Timer();
            timer.Elapsed += (s, e) =>
            {
                source.Change();
            };
            timer.Interval = 3000;//3秒更新一次
            timer.Start();
        });
        ...
    }

　　这里采用定时器模拟，真实环境可能是采用一条消息总线或者是消息队列的通知来实现。

　　这里为名称是Client1的Client添加定时刷新Options缓存的机制，而Client2不变，当运行项目后，再次调用Cient接口，会发现Client1的Time每个3秒刷新一次，而Client2则不变：

　　

　　

　　四、总结

　　有关Options的内容就说完了，把它和IConfiguration结合起来是一种非常好的配置形式，这也是.net core开发的基础，上面的例子也比较清楚，应该都能理解吧。