ASP.NET Core的配置(3): 将配置绑定为对象[下篇]
2016-04-21 22:25
846 查看
我们在《读取配置信息》通过实例的形式演示了如何利用Options模型以依赖注入的方式直接获取由指定配置节绑定生成的Options对象,我们再次回顾一下当初我们编写的程序。如下面的代码片段所示,基于Options模型的配置绑定的编程基本采用这样的模式:先后调用ServiceCollection的扩展方法AddOption和Configure注册Options模型相关的服务并完成Options类型与指定配置节之间的映射,然后利用由此生成ServiceProvider获得一个类型为IOptions<TOptions>的服务示例,后者的Value就是配置绑定生成的Options对象。
由于Options模型的编程仅仅涉及到上述几个方法的调用,所以只要搞清楚这几个方法背后的实现逻辑,我们也就彻底了解了Options模型的实现原理。首先当我们调用ServiceCollection的扩展方法时,实际上仅仅是按照如下的方式注册了一个针对IOptions <TOptions>接口类型的服务而已。服务接口IOptions<TOptions>仅仅定义了一个只读属性Value,该属性返回的正是绑定了指定配置数据的Options对象。
通过上面的给出的代码片段我们不难看出,AddOptions方法实际上是以Singleton模式注册了一个类型为OptionsManager<TOptions>的服务,如下所示的代码片段基本反映了该类型的实现逻辑。如下面的代码片段所示,OptionsManager<TOptions>的只读属性Value返回的Options对象是以“延迟加载(Lazy Loading)”的形式被提供。Options对象创建的逻辑也很简单,我们直接调用其默认构造函数创建一个空的Options对象,然后将其递交给在构造函数中指定的一系列IConfigureOptions<TOptions>进行设置,配置绑定就这这个过程中完成。
IConfigureOptions<TOptions>接口抽象了针对Options对象的配置行为,这个行为体现在定义其中的Configure方法。ConfigureOptions<TOptions>实现了这个接口,它采用在构造函数提供的Action<TOptions>完成对Options对象的配置。
针对Options对象的配置绑定工作实现在一个名为ConfigureFromConfigurationOptions<TOptions>的类中。如下面的代码片段所示,这个类型直接继承ConfigureOptions<TOptions>,在构造函数中指定的Configuration对象承载了最终需要绑定到Options对象上的配置数据,它直接调用Configuration对象的扩展方法Bind完成了针对Options对象的配置绑定。
在Options模型中,ConfigureFromConfigurationOptions<TOptions>对象通过扩展方法Configure方法被注册到指定的ServiceCollection对象中。如下面的代码片段所示,Configure方法直接利用作为参数传入的Configuration对象创建一个ConfigureFromConfigurationOptions<TOptions>对象,并将这个对象注册到ServiceCollection之中。
整个Options模型以两个注册到ServiceCollection的服务为核心,这两个服务对应的服务接口分别是IOptions <TOptions>和IConfigureOptions<TOptions>,前者直接提供最终绑定了配置数据的Options对象,后者则在Options对象返回之前对它实施相应的初始化工作。这个两个服务分别通过扩展方法AddOptions和Configure方法注册到指定的ServiceCollection之中,服务的真实类型分别是OptionsManager<TOptions>和ConfigureFromConfigurationOptions<TOptions>,后者派生于ConfigureOptions<TOptions>。右图所示的UML体现了Options模型中涉及的这些接口和类型之间的关系。
对于一个包含服务注册描述信息的ServiceCollection,当我们分别调用其扩展方法AddOptions和Configure完成了相应的服务注册之后,我们就可以利用由它生成的ServiceProvider对象来提供针对接口类型IOptions <TOptions>的服务实例,并通过后者的只读属性Value得到配置绑定生成的Options对象。
ServiceProvider提供的这个服务实例自然是一个OptionsManager<TOptions>对象,当ServiceProvider调用构造函数对它进行实例化的时候,我们注册的ConfigureFromConfigurationOptions<TOptions>对象会以构造器注入的形式作为参数。在构造函数执行过程中,一个空的Options对象先被创建出来后会作为参数调用ConfigureFromConfigurationOptions<TOptions>的Configure方法,后者将在预先指定的Configuration对象绑定到这个Options对象之上。
ASP.NET Core的配置(1):读取配置信息
ASP.NET Core的配置(2):配置模型详解
ASP.NET Core的配置(3): 将配置绑定为对象[上篇]
ASP.NET Core的配置(3): 将配置绑定为对象[下篇]
ASP.NET Core的配置(4):多样性的配置源[上篇]
ASP.NET Core的配置(4):多样性的配置源[中篇]
ASP.NET Core的配置(4):多样性的配置源[下篇]
ASP.NET Core的配置(5):配置的同步[上篇]
ASP.NET Core的配置(5):配置的同步[下篇]
[code] FormatSettings settings = new ServiceCollection()
.AddOptions()
.Configure<FormatSettings>(configuration)
.BuildServiceProvider()
.GetService<IOptions<FormatSettings>>()
.Value;
一、IOptions <TOptions>
由于Options模型的编程仅仅涉及到上述几个方法的调用,所以只要搞清楚这几个方法背后的实现逻辑,我们也就彻底了解了Options模型的实现原理。首先当我们调用ServiceCollection的扩展方法时,实际上仅仅是按照如下的方式注册了一个针对IOptions <TOptions>接口类型的服务而已。服务接口IOptions<TOptions>仅仅定义了一个只读属性Value,该属性返回的正是绑定了指定配置数据的Options对象。[code] public static class ServiceCollectionExtensions
{
public static IServiceCollection AddOptions(this IServiceCollection services)
{
return services.AddSingleton(typeof(IOptions<>), typeof(OptionsManager<>));
}
}
public interface IOptions<TOptions> where TOptions:class, new()
{
TOptions Value{ get;}
}
通过上面的给出的代码片段我们不难看出,AddOptions方法实际上是以Singleton模式注册了一个类型为OptionsManager<TOptions>的服务,如下所示的代码片段基本反映了该类型的实现逻辑。如下面的代码片段所示,OptionsManager<TOptions>的只读属性Value返回的Options对象是以“延迟加载(Lazy Loading)”的形式被提供。Options对象创建的逻辑也很简单,我们直接调用其默认构造函数创建一个空的Options对象,然后将其递交给在构造函数中指定的一系列IConfigureOptions<TOptions>进行设置,配置绑定就这这个过程中完成。
[code] public class OptionsManager<TOptions> : IOptions<TOptions> where TOptions : class, new()
{
private Lazy<TOptions> optionsAccessor;
public OptionsManager(IEnumerable<IConfigureOptions<TOptions>> setups)
{
optionsAccessor = new Lazy<TOptions>(() =>
{
TOptions options = new TOptions();
setups.ForEach(it => it.Configure(options));
return options;
});
}
public TOptions Value
{
get{ return optionsAccessor.Value;}
}
}
二、IConfigureOptions<TOptions>
IConfigureOptions<TOptions>接口抽象了针对Options对象的配置行为,这个行为体现在定义其中的Configure方法。ConfigureOptions<TOptions>实现了这个接口,它采用在构造函数提供的Action<TOptions>完成对Options对象的配置。[code] public interface IConfigureOptions<TOptions> where TOptions : class, new()
{
void Configure(TOptions options);
}
public class ConfigureOptions<TOptions> : IConfigureOptions<TOptions> where TOptions : class, new()
{
public Action<TOptions> Action{ get; private set;}
public ConfigureOptions(Action<TOptions> action)
{
this.Action = action;
}
public void Configure(TOptions options)
{
this.Action(options);
}
}
针对Options对象的配置绑定工作实现在一个名为ConfigureFromConfigurationOptions<TOptions>的类中。如下面的代码片段所示,这个类型直接继承ConfigureOptions<TOptions>,在构造函数中指定的Configuration对象承载了最终需要绑定到Options对象上的配置数据,它直接调用Configuration对象的扩展方法Bind完成了针对Options对象的配置绑定。
[code] public class ConfigureFromConfigurationOptions<TOptions>: ConfigureOptions<TOptions> where TOptions : class, new()
{
public ConfigureFromConfigurationOptions(IConfiguration configuration) : base(options => configuration.Bind(options))
{}
}
在Options模型中,ConfigureFromConfigurationOptions<TOptions>对象通过扩展方法Configure方法被注册到指定的ServiceCollection对象中。如下面的代码片段所示,Configure方法直接利用作为参数传入的Configuration对象创建一个ConfigureFromConfigurationOptions<TOptions>对象,并将这个对象注册到ServiceCollection之中。
[code] public static class ServiceCollectionExtensions
{
public static IServiceCollection Configure<TOptions>(this IServiceCollection services, IConfiguration configuration)
where TOptions : class, new()
{
return services.AddInstance<IConfigureOptions<TOptions>>(new ConfigureFromConfigurationOptions<TOptions>(configuration));
}
}
三、Options对象的提供
整个Options模型以两个注册到ServiceCollection的服务为核心,这两个服务对应的服务接口分别是IOptions <TOptions>和IConfigureOptions<TOptions>,前者直接提供最终绑定了配置数据的Options对象,后者则在Options对象返回之前对它实施相应的初始化工作。这个两个服务分别通过扩展方法AddOptions和Configure方法注册到指定的ServiceCollection之中,服务的真实类型分别是OptionsManager<TOptions>和ConfigureFromConfigurationOptions<TOptions>,后者派生于ConfigureOptions<TOptions>。右图所示的UML体现了Options模型中涉及的这些接口和类型之间的关系。
对于一个包含服务注册描述信息的ServiceCollection,当我们分别调用其扩展方法AddOptions和Configure完成了相应的服务注册之后,我们就可以利用由它生成的ServiceProvider对象来提供针对接口类型IOptions <TOptions>的服务实例,并通过后者的只读属性Value得到配置绑定生成的Options对象。
ServiceProvider提供的这个服务实例自然是一个OptionsManager<TOptions>对象,当ServiceProvider调用构造函数对它进行实例化的时候,我们注册的ConfigureFromConfigurationOptions<TOptions>对象会以构造器注入的形式作为参数。在构造函数执行过程中,一个空的Options对象先被创建出来后会作为参数调用ConfigureFromConfigurationOptions<TOptions>的Configure方法,后者将在预先指定的Configuration对象绑定到这个Options对象之上。
ASP.NET Core的配置(1):读取配置信息
ASP.NET Core的配置(2):配置模型详解
ASP.NET Core的配置(3): 将配置绑定为对象[上篇]
ASP.NET Core的配置(3): 将配置绑定为对象[下篇]
ASP.NET Core的配置(4):多样性的配置源[上篇]
ASP.NET Core的配置(4):多样性的配置源[中篇]
ASP.NET Core的配置(4):多样性的配置源[下篇]
ASP.NET Core的配置(5):配置的同步[上篇]
ASP.NET Core的配置(5):配置的同步[下篇]
相关文章推荐
- raspberry树莓派自启动vnc
- 【Raspberry Pi 3试用体验】+wifi的一些问题
- Asp.Net ORM
- MVC中路由器的使用
- ASP.NET: 正在中止线程 错误原及解决方法
- mvc中自定义验证逻辑
- ASP.NET程序通过web.config为网站添加MIME
- Asp.net面试题
- ASP.NET MVC之文件上传【一】(八)
- 在ASP.NET中自动合并小图片并使用CSS Sprite显示出来
- asp.net生成店铺推广二维码,二维码中间加logo(源码)
- ASP.NET MVC 3 入门级常用设置、技巧和报错
- 支持Ajax跨域访问ASP.NET Web Api 2(Cors)的示例教程
- asp.net core 中的MD5加密
- Autofac 依赖注入 ASP.NET MVC5 插件机制中插件的简单实现
- Asp.net MVC进入请求管道的过程
- asp.net mvc5中使用缓存依赖SqlCacheDependency
- asp.net Sql缓存依赖(SqlCacheDependency)简介
- ASP.NET MVC动态生成网站菜单及子菜单
- asp.net 缓存公共类