前言
来啦！来啦！上一节一堆代码，是不是感觉甚是无味啊？没关系，这里结合上一节内容专注举例演示，绝不废话！走起~~~~~
正文
老规矩，一个WebApi项目走起，项目结构如下：
上一节中提到，Options是基于依赖注入的，所以我们需要将相关服务进行注册，如下：
注册完成之后就可以直接用啦，这里新建了一个ComputerController进行测试：
运行走起：
通常在使用的时候，相关服务的配置会放到配置文件中，比如数据库连接字符串等，所以在注册的时候将初始化的内容从配置中获取即可，如下：
跑起来~~~
通过以上的实例演示，可能会好奇为啥不直接用Configuration，我是这样理解的：通过Options的话，服务不限制使用初始化方式，根据需求选择，如果使用配置文件取值，服务也和配置没有直接关系，从而使得服务的使用没有过多限制；另外服务内部使用也比较便捷，就单纯操作Options对象；
哎呀，又来这一套，使用太简单了，来点真货呗，此时应该有小伙伴按捺不住了问：Options的相关服务是怎么注册的，初始化和上一节讲的初始化有啥关系？ 来来来，不急，以下慢慢品~~~
那从哪开始呢？
上一小节说的TOptions对象创建的三大步，创建内部直接New了(忘了的可以回顾一下上一节:跟我一起学.NetCore之选项(Options)核心类型简介)，那这里就从注册初始化的地方下手：
Services.Configure方法中肯定有事，不然一句代码咋就让后面使用如此便捷呢，来，直接看源代码：
// Copyright (c) .NET Foundation. All rights reserved.
// Licensed under the Apache License, Version 2.0. See License.txt in the project root for license information.
using System;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.Options;
namespace Microsoft.Extensions.DependencyInjection
{
///
/// Extension methods for adding configuration related options services to the DI container.
///
public static class OptionsConfigurationServiceCollectionExtensions
{
// 挨着的这三个方法都是IServiceCollection 的扩展方法
public static IServiceCollection Configure(this IServiceCollection services, IConfiguration config) where TOptions : class
=> services.Configure(Options.Options.DefaultName, config);
public static IServiceCollection Configure(this IServiceCollection services, string name, IConfiguration config) where TOptions : class
=> services.Configure(name, config, _ => { });
public static IServiceCollection Configure(this IServiceCollection services, IConfiguration config, Action configureBinder)
where TOptions : class
=> services.Configure(Options.Options.DefaultName, config, configureBinder);
// 关键方法
public static IServiceCollection Configure(this IServiceCollection services, string name, IConfiguration config, Action configureBinder)
where TOptions : class
{
if (services == null)
{
throw new ArgumentNullException(nameof(services));
}
if (config == null)
{
throw new ArgumentNullException(nameof(config));
}
// 注册Options相关服务，这是关键方法
services.AddOptions();
// IOptionsChangeTokenSource 注册，后续用于通知
services.AddSingleton>(new ConfigurationChangeTokenSource(name, config));
// 注册从配置系统中获取配置值的服务
return services.AddSingleton>(new NamedConfigureFromConfigurationOptions(name, config, configureBinder));
}
}
}
上面代码中services.AddOptions()是关键方法，再翻代码瞅瞅：
public static class OptionsServiceCollectionExtensions
{
// 恍然大悟吧，就是这个扩展方法，把服务都注册好了，所以使用的时候才直接注入即可
public static IServiceCollection AddOptions(this IServiceCollection services)
{
if (services == null)
{
throw new ArgumentNullException(nameof(services));
}
// 使用TryAdd的注入方式，为了对应服务类型只注册一次
// 注册IOptions<>，实现类是OptionsManager<>
services.TryAdd(ServiceDescriptor.Singleton(typeof(IOptions<>), typeof(OptionsManager<>)));
// 注册IOptionsSnapshot<>，实现类是OptionsManager<>
services.TryAdd(ServiceDescriptor.Scoped(typeof(IOptionsSnapshot<>), typeof(OptionsManager<>)));
// 注册IOptionsMonitor<>,实现类是OptionsMonitor<>
services.TryAdd(ServiceDescriptor.Singleton(typeof(IOptionsMonitor<>), typeof(OptionsMonitor<>)));
// 注册IOptionsFactory<> ,实现类是OptionsFactory<>
services.TryAdd(ServiceDescriptor.Transient(typeof(IOptionsFactory<>), typeof(OptionsFactory<>)));
// 注册IOptionsMonitorCache<>, 实现类是OptionsCache<>
services.TryAdd(ServiceDescriptor.Singleton(typeof(IOptionsMonitorCache<>), typeof(OptionsCache<>)));
return services;
}
// 对应创建TOption 初始化的两小步，步骤1Configure
public static IServiceCollection Configure(this IServiceCollection services, string name, Action configureOptions)
where TOptions : class
{
if (services == null)
{
throw new ArgumentNullException(nameof(services));
}
if (configureOptions == null)
{
throw new ArgumentNullException(nameof(configureOptions));
}
services.AddOptions();
services.AddSingleton>(new ConfigureNamedOptions(name, configureOptions));
return services;
}
// 对应创建TOption 初始化的两小步，步骤2 PostConfigure
public static IServiceCollection PostConfigure(this IServiceCollection services, string name, Action configureOptions)
where TOptions : class
{
if (services == null)
{
throw new ArgumentNullException(nameof(services));
}
if (configureOptions == null)
{
throw new ArgumentNullException(nameof(configureOptions));
}
services.AddOptions();
services.AddSingleton>(new PostConfigureOptions(name, configureOptions));
return services;
}
......省略了其他方法....
}
看了以上代码，是不是豁然开朗了，Options的相关服务注册都是在AddOptions扩展方法中完成的，至于其中的Configure和PostConfigure实则对应着上一节的创建Options初始化的过程；以上注册的核心类型的生命周期需要了解一下，后面举例会关联到：
-
IOptions<>：Singleton - 单例模式
-
IOptionsSnapshot<>：Scoped - 作用域范围模式
-
IOptionsMonitor<>: Singleton - 单例模式
Configure是注册时进行初始化，而PostConfigure一般会用在读取到配置数据之后对数据进行加工，如下：
接下来说热更新，也就是配置改变，服务对应的Options能获取最新的值，代码稍微优化一下：
第一次访问，第二次访问前进行配置文件修改，然后在访问，运行结果如下：
可以看到，配置数据改变时，IOptionsSnapshot<>和IOptionsMonitor<>都能获取到最新的值，IOptions<>没有获取到，简单分析一下：
IOptons<>和IOptionsSnapshot<>其实内部是一样的，只是注入的生命周期不一样，前者是单例，后者是Scoped，这样就使得后者每次请求都是不同的IOptionsSnapshot对象，从而就能获取最新的值；而单例IOptions对象一致不变；那为什么单例的IOptionsMonitor类型能改变呢，那是因为IOptionsMonitor提供了监听改变的功能，上一节有简单说明；
如果在配置数据改变时，需要通知Option怎么办呢？通过IOptionsMonitor 的OnChange监听改变，如下：
运行看结果，首先请求一次，然后修改配置文件，就能看到实时监控了：
最后来说说Options验证(也就是创建TOptions的第三步)，主要是避免不合法的配置，导致程序在运行时业务逻辑出错才能发现错误，从而导致程序迭代周期频繁，用户体验差；验证有以下三种方式：
-
直接注册验证函数
-
实现IValidateOptions 进行验证
-
使用注解(Microsoft.Extensions.Options.DataAnnotations)
这里用三种方式分别依次验证Name，Cores，MemorySize 三个配置项，如下：
-
直接注册验证函数
-
实现IValidateOptions 进行验证
-
使用注解(Microsoft.Extensions.Options.DataAnnotations)
三种验证方式是相互独立的，可以单独使用，也可以组合使用；以上每一种方式对应图片内容；
运行访问不合法就报错，这样就避免配置不合法，导致业务逻辑不合法，如下
总结
Options(选项)的常规用法暂时就说这么多了，结合上一小节是不是感觉清晰多了~~~下一节说说日志（ILogger）
----------------------------------------------
一个被程序搞丑的帅小伙，关注"Code综艺圈"，识别关注跟我一起学~~~