ASP.NET Core开发的选项模式
- 作者: 时间-problem
- 来源: 51数据库
- 2021-08-12
- 选项接口
- 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
