• 选项接口
  • ioptionssnapshot与ioptionsmonitor的区别
  • 选项的后期配置
  • 选项的验证

asp.net core笔记(3) – 配置中介绍了各种配置提供程序以及配置的读取方式,但实际使用中,不推荐应用程序直接从一堆配置中读取的做法,而是使用强类型绑定,将配置按组绑定到不同服务所属的类。使用这种方式可以让配置方案遵守两个重要的软件工程原则:

  • 接口分离原则 (isp) 或封装 – 依赖于配置设置的方案(类)仅依赖于其使用的配置设置。
  • 关注点分离 – 应用的不同部件的设置不彼此依赖或相互耦合。

选项接口

asp.net core选项模式常用的接口有

  • ioptions
  • ioptionssnapshot
  • ioptionsmonitor

ioptions在配置更改时无法对应变更选项的值,只能重启应用。ioptionssnapshot和ioptionsmonitor则具有这种能力。

选项可以作为服务在使用时被注入,下面的代码模拟了选项的使用场景,orderserviceoptions作为orderservice的选项被注入,orderservice又在控制器中被注入:

public interface iorderservice
{
    int showmaxordercount();
}

public class orderservice : iorderservice
{
    ioptionssnapshot<orderserviceoptions> _options;
    public orderservice(ioptionssnapshot<orderserviceoptions> options)
    {
        _options = options;
    }

    public int showmaxordercount()
    {
        return _options.value.maxordercount;
    }
}

public class orderserviceoptions
{
    public int maxordercount { get; set; };
}

控制器中注入orderservice:

[httpget]
public string get([fromservices]iorderservice orderservice)
{
    var res = $"orderservice.showmaxordercount:{orderservice.showmaxordercount()},time={orderservice.showtime()}";
    console.writeline(res);
    return res;
}

在configservice配置orderserviceoptions和orderservice的注入:

services.configure<orderserviceoptions>(configuration.getsection("orderservice"));
services.addscoped<iorderservice, orderservice>();

ioptionssnapshot与ioptionsmonitor的区别

这里注入时使用的是addscoped作用域的方式,是因为使用了ioptionssnapshot接口。ioptionssnapshot的生命周期为作用域,会在每次请求时应重新读取配置、更新选项。所以修改配置后,重新请求api,就可以看到最新的配置值。
如果尝试选择addsingleton,由于orderservice单例的生命周期比ioptionssnapshot更长,会直接抛出运行时异常。

而如果遇到既需要单例生命周期,还需要变更检测的场景时怎么办呢?这时就需要用到ioptionsmonitor了。
ioptionsmonitor 和 ioptionssnapshot 之间的区别在于:

  • ioptionsmonitor 是一种单例服务,且可以监测配置的变更。
  • ioptionssnapshot 是一种作用域服务,并在构造 ioptionssnapshot 对象时提供选项的快照。

ioptionsmonitor使用与ioptionssnapshot类似,但取值变为currentvalue。如果修改配置源,就会触发onchange方法:

_options.onchange(option =>
{
    console.writeline($"配置更新了,最新的值是:{_options.currentvalue.maxordercount}");
});

ioptionsmonitor还可以结合asp.net core笔记(3) – 配置中介绍的自定义数据源的方法,当iconfigurationprovider触发onreload()事件时,这里的onchange也就会被触发。

选项的后期配置

使用postconfigure可进行选项的后期配置:

services.postconfigure<orderserviceoptions>(options =>
{
    options.maxordercount += 20;
});

选项的验证

为了防止应用程序读取到错误的配置,可以为选项添加验证。
选项验证有三种方式:

  • 直接注册验证函数
  • dataannotations
  • 实现ivalidateoptions接口

直接注册验证函数

添加选项需要替换为addoptions

//services.configure<orderserviceoptions>(configuration);
services.addoptions<orderserviceoptions>().bind(configuration).configure(options =>
{
configuration.bind(options);
})
.validate(options => options.maxordercount <= 100, "maxordercount不能大于100");

dataannotations

调用validatedataannotations:

services.addoptions<orderserviceoptions>().bind(configuration).configure(options =>
{
configuration.bind(options);
})
.validatedataannotations<orderserviceoptions>();

为选项模型类添加annotation:

public class orderserviceoptions
{
    [range(0, 100)]
    public int maxordercount { get; set; };
}

实现ivalidateoptions接口

注册验证服务:

services.addoptions<orderserviceoptions>().bind(configuration).configure(options =>
{
configuration.bind(options);
})
.services.addsingleton<ivalidateoptions<orderserviceoptions>,orderservicevalidateoptions> ();

实现ivalidateoptions:

public class orderservicevalidateoptions : ivalidateoptions<orderserviceoptions>
{
    public validateoptionsresult validate(string name, orderserviceoptions options)
    {
        if (options.maxordercount > 100)
        {
            return validateoptionsresult.fail("maxordercount不能大于100");
        }
        else
        {
            return validateoptionsresult.success;
        }
    }
}
转自:https://www.cnblogs.com/zhixin9001/p/12708713.html