网站开发可以学吗,个人信用信息公示系统,网站标题符号有哪些,大人和小孩做系列网站在上面一章我们以实例演示的方式介绍了几种读取配置的几种方式#xff0c;其中涉及到三个重要的对象#xff0c;它们分别是承载结构化配置信息的Configuration#xff0c;提供原始配置源数据的ConfigurationProvider#xff0c;以及作为“中间人”的ConfigurationBuilder。… 在上面一章我们以实例演示的方式介绍了几种读取配置的几种方式其中涉及到三个重要的对象它们分别是承载结构化配置信息的Configuration提供原始配置源数据的ConfigurationProvider以及作为“中间人”的ConfigurationBuilder。接下来我们将会对由这三个核心对象组成的配置模型进行详细介绍不过在此之前我们有必要来认识配置信息在不同载体中所体现出来的三种结构。 一、配置的三种结构 相同的数据具有不同的表现和承载方式同时体现出不同的数据结构。对于配置来说它在消费过程中是以Configuration对象的形式来体现的该对象逻辑上具有一个树形化的层次结构。配置具有多种来源可以是内存对象、物理文件或者数据库不同类型的数据源决定了不同的配置结构。我们将这两种结构称为逻辑结构和原始结构。在这两种结构之间配置还存在一种中间结构我们姑且称之为物理结构。 逻辑结构 配置的逻辑结构就是Configuration对象所体现的结构说得更加准确一点应该是针对Configuration对象的API所体现的结构因为不是所有的Configuration对象内部都封装一组配置数据。配置在逻辑上呈现为一种树形结构我们称之为配置树组成这棵树的某个节点就体现为一个Configuration对象。表现为键值对的原子配置项存储于叶子节点中而非叶子节点仅仅体现为一个配置节点的逻辑容器自身不包含具体的配置数据。对于我们在第一节定义的FormatSettings来说它对应的配置具有如右图所示的逻辑结构。 原始结构 配置采用怎样的原始结构取决于我们采用何种方式定义它。最常见的配置源体现为采用某个格式的文本文件那么配置的原始结构则由文件的格式来决定。对于我们在第一节定义的FormatSettings类型我们可以按照如下的形式以XML和JSON的格式来定义其配置。 XML: JSON: 物理结构 配置模型的终极目的就是将配置从原始结构转换成逻辑结构。不过在进行结构转化的时候它并不会直接将原始的配置数据转换成一个Configuration对象它们之间由一种被我称为物理结构的中间结构作为过度。配置的物理结构体现为一个简单的数据字典。同样是针对FormatSettings这个类型对应的配置将具有如下表所示的物理结构。 结构转换 配置模型的终极目的在于将具有不同来源的配置转换成Configuration对象配置源和Configuration对象本身分别体现了配置的原始结构和逻辑结构所以配置模型旨在实现配置数据从原始结构向逻辑结构的转换。在具体转换过程中配置模型先利用与配置源相对应的ConfigurationProvider将配置数据从原始结构转换成体现为数据字典的物理结构。当我们利用ConfigurationBuilder生成Configuration的时候实际上将配置数据从物理结构转换成逻辑结构。 二、Configuration 我们在上面以数据结构转换的角度分析了Configuratin、ConfigurationProvider和ConfigurationBuilder这三个核心对象在配置模型中所起的作用接下来让我们来更加深入地认识它们。我们首先来介绍Configuration对象本章不断提及的Configuration泛指类型实现了IConfiguration接口的对象该接口定义在“Microsoft.Extensions.Configuration”命名空间下如果未作特别说明本章涉及到的与配置相关的类型均定义在此命名空间下。 配置具有树形逻辑结构一个Configuration对象表示配置树的某个配置节点。对于组成整棵树的所有配置节点来说表示根节点的Configuration对象与表示其它配置节点的Configuration对象相比具有不同的特性所以配置模型采用不同的接口来表示它们。具体来说基于根节点的Configuration对象通过接口IConfigurationRoot表示另一个接口IConfigurationSection则表示针对非空节点的Configuration对象两个接口都继承IConfiguration。如右图所示一棵完整的配置树由一个ConfigurationRoot对象和若干ConfigurationSection构成。 ConfigurationRoot 我们将所有实现了IConfigurationRoot接口的类型和其对象统称为ConfigurationRoot。如下面的代码片段所示IConfigurationRoot仅仅包含一个唯一的方法Reload实现对配置数据的重新加载。一个ConfigurationRoot对象表示配置数的根节点如果它被重新加载了那么这颗配置树承载的所有配置数据均被重新加载了。 ConfigurationSection 我们将所有实现了IConfigurationSection接口的类型及其对象统称为ConfigurationSection一个ConfigurationSection对应着配置树中某个非根配置节。IConfigurationSection具有如下三个属性只读属性Key用来唯一标识多个“同父”配置节而另一个只读属性Path则表示从根节点到父节点的路径该路径由ConfigurationSection的Key组成并采用冒号作为分隔符。Path和Key的组合体现了当前配置节在整个配置树中的位置。 IConfigurationSection的Value属性表示配置节的值在大部分情况下只有配置树叶子结点对应的ConfigurationSection对象才具有值非叶子节点对应的ConfigurationSection对象实际上仅仅表示一组隶属于它的所有子配置节的逻辑容器它们的Value一般返回Null。值得一体的是这个Value属性并不是只读的而是可读可写的。 在对ConfigurationRoot和ConfigurationSection具有基本了解情况下我们回过头来看看定义在接口IConfiguration中的成员。它的GetChildren方法返回一组表示其子配置节的ConfigurationSection对象集合另一个方法GetSection则根据指定的Key返回对应的ConfigurationSection对象。当GetSection方法执行的时候指定的参数将会与当前ConfigurationSection的Path进行组合以确定目标ConfigurationSection所在的路径所以如果在调用该方法的时候指定一个相对于当前配置节的路径我们是可以得到子节点以下的某个配置节。 如上面的代码片段所示我们以不同的方式调用GetSection方法得到的都是路径为“Format:DateTime:LongDatePattern”的ConfigurationSection。上面这段代码还体现了另一个有趣的现象虽然这三个ConfigurationSection对象均指向配置树的同一个节点但是它们却并非同一个对象。换句话说当我们调用GetSection方法的时候不论配置树种是否存在一个与指定路径匹配的配置节它总是会创建一个全新的ConfigurationSection对象。 IConfiguration还具有一个索引我们可以指定子配置节的Key或者相对当前配置节的路径得到对应配置节的值。当这个索引执行的时候它会按照与GetSection方法完全一致的逻辑得到一个ConfigurationSection对象并返回其Value属性。如果配置树中不具有匹配的配置节该索引会返回Null而不会抛出异常。 三、ConfigurationProvider 为配置模型提供原始配置数据的ConfigurationProvider是对所有实现了IConfigurationProvider接口的所有类型及其对象的统称。从配置数据结构转换的角度来看ConfigurationProvider的目的在于将配置数据从原始结构转换成物理结构由于配置数据的物理结构体现为一个简单的二维数据字典所以我们会发现定义在IConfigurationProvider接口中的方法大都体现为针对字典对象的相关操作。 配置数据的加载通过调用ConfigurationProvider的Load方法来完成。我们可以调用TryGet方法获取有指定的Key所标识的配置项的值。从数据持久化的角度来讲ConfigurationProvider基本上都是只读的也就是说ConfigurationProvider只负责从持久化资源中读取配置数据而不负责更新保存在持久化资源的配置数据所以它提供的Set方法设置的配置数据一般只会保存在内存中。ConfigurationProvider的GetChildKeys方法用于获取指定路径对应配置节的所有子节点的Key。 每种不同类型的配置源都具有对应的ConfigurationProvider它们对应的类型大都不会直接实现IConfigurationProvider接口而是继承另一个名为ConfigurationProvider的抽象类。这个抽象类的定义其实很简单从如下的代码片段可以看出它仅仅是对一个IDictionarystring, string对象的封装其Set和TryGetValue方法最终操作的都是这个字典对象。它实现了Load方法并将其定义成虚方法具体的ConfigurationProvider可以通过重写这个方法从相应的数据源中读取配置数据并对这个字典对象进行初始化。 接下来我们简单介绍一下定义在这个抽象类中GetChildKeys方法的逻辑。采用基于路径的Key让数据字典在逻辑上具有了树形化层次结构而这个方法用于获取将指定配置节作为父节点的所有配置节的Key。指定的父配置节通过参数parentPath表示的路径来体现另一个参数delimiter则表示路径采用的分隔符。除此之外这个方法还具有一个字符串集合类型的参数earlierKeys它表示预先解析出来的Key这个列表会包含在返回的结果中。 为了让读者朋友们能够更加直观地理解GetChildKeys方法的逻辑我们编写了如上一段实例程序。我们创建了一个MemoryConfigurationProvider对象由塔封装的配置数据字段包含三个元素它们对应的Key分别是“ABC”、“ABD”和“AE”。我们调用它的GetChildKeys方法并将表示父节点的路径分别指定为“A”、“AB和“ABC”以获取相应子节点的Key。除此之外我们采用冒号“”作为分隔符并将earlierKeys指定为包含“X”、“Y”和“Z”三个元素的数组。这段程序执行之后会在控制台上产生如下的输出结果我们从中可以看出一个细节返回的结构并没有将重复的Key剔除。 四、ConfigurationBuilder ConfigurationBuilder泛指所有实现了IConfigurationBuilder接口的类型及其对象它在配置模型中的作用就是利用注册的ConfigurationProvider提取转换成数据字典的配置数据并创建对应的Configuration对象具体来说创建的是一个体现配置树的ConfigurationRoot对象。注册到ConfigurationBuilder上的ConfigurationProvider体现为IConfigurationBuilder接口的Providers属性我们可以调用Add方法将ConfigurationProvider添加到这个集合中。 除此之外IConfigurationBuilder还具有一个字典类型的只读属性Properties我们可以将任意自定义的属性附加当一个ConfigurationBuilder对象上并通过对应的Key得到这些属性值。ConfigurationRoot的创建最终通过Build方法完成。 原生的配置模型中提供了一个实现IConfigurationBuilder接口的类型那就是在我们之前演示的实例中多次使用的ConfigurationBuilder类配置模型默认的配置生成机制体现在它实现的Build方法中。具体来说实现在ConfigurationBuilder类中的Build方法返回对象的真实类型为ConfigurationRoot该对象通过一个类型为ConfigurationSection对象表示非根配置节。右图所示的UML展示了配置模型中以Configuration、ConfigurationProvider和ConfigurationBuilder为核心的相关接口/类型以及它们之前的关系。 ConfigurationRoot和ConfigurationSection这个两个类型的定义体现配置模型默认采用怎样的机制读取配置数据这是我们本节论述的重点内容。虽然配置模型最终提供的配置数据通过Configuration对象来体现但是不论ConfigurationRoot还是ConfigurationSection对象它们自身本没有封装任何的形式的配置数据所有针对它们的数据读写操作最终都会转移到相应的ConfigurationProvider上。由于Configuration对象仅仅体现为ConfigurationProvider的代理所以由同一个ConfigurationBuilder创建的所有ConfigurationRoot对象都是等效的下面的代码片段体现了这样的等效性。 组成配置树的ConfigurationRoot和ConfigurationSection不但自身封装和配置数据配置节父子关系的维护也并不直接通过对象之间的引用关系来维系。如右图所示对于一个表示配置树中某个非根配置节的ConfigurationSection对象来说它仅仅保留着对根节点的引用后者是一个类型为ConfigurationRoot的对象。当我们调用ConfigurationSection方法获取或者设置配置数据的时候它会直接将调用请求转发给表示配置树根的ConfigurationRoot对象。 具体来说当我们试图通过某个ConfigurationSection对象得到对应配置节点的值时该对象会将配置数据的读取请求转发给它所引用的表示数值树根的ConfigurationRoot对象同时将自身的路径一并传递给后者。ConfigurationRoot最终利用ConfigurationProvider根据指定的路径得到对应配置项的值左图揭示了这样的流程。 在对实现在ConfigurationRoot和ConfigurationSection这两个类中针对配置的读写机制有了大概的了解之后我们从代码实现的角度来进一步地来认识这两个类型在这之前我们需要先来认识一个名为ConfigurationPath的工具类。顾名思义ConfigurationPath帮助我们实现针对配置树路径相关的计算其中Combine方法将多个片段合并成一个完整的路径GetSectionKey方法会根据指定的路径得到对应的Key而GetParentPath则根据指定的路径得到上一级的路径。 ConfigurationRoot ConfigurationRoot真实的实现逻辑基本上体现在如下所示的代码片段中。一个ConfigurationRoot对象维护着一组提供原始配置数据的ConfigurationProvider对象每一次对配置数据的读写操作最终都会转移到它们头上。当调用它的索引指定相应的Key获取对应配置项的值时我们会将这组ConfigurationProvider对象进行逆向排序并将指定的Key作为参数依次调用每个ConfigurationProvider的TryGet方法直到该方法返回True并将这个方法返回的值最为索引最终的返回值。当我们利用索引对指定配置项的值进行设置的时候实际上会调用每个ConfigurationProvider的Set方法。 ConfigurationRoot实现在索引中读取配置的逻辑体现了配置模型一个重要的特性那就是如果某个配置项的数据具有多个来源那么最后添加到ConfigurationBuilder中的ConfigurationProvider具有更高的优先级我们姑且将这个特性称为ConfigurationProvider“后来居上”的原则。如果希望覆盖应用现有的某个配置我们只需要将提供新配置的ConfigurationProvider添加到ConfigurationBuilder之上即可。 我们定义了一个辅助方法GetChildrenCore来获取某个配置节的所有子配置节这个指定的配置节通过作为参数的路径来表示。当这个方法执行之后所有ConfigurationProvider的GetChildKeys方法会被调用以获取所有子配置节的Key我们利用它们生成表示配置节的ConfigurationSection对象。在实现的GetChildren方法中我们会调用这个方法来获取隶属于自己的所有子配置节。而另一个GetSection方法中我们直接返回根据指定路径对于表示根配置节来说参数key表示配置节的路径创建的ConfigurationSection对象。 ConfigurationSection 在上面关于用于模拟ConfigurationRoot类型定义的代码中我们知道最终表示非根配置节的ConfigurationSection对象是根据它的路径和作为根配置节的ConfigurationRoot对象创建的。ConfigurationRoot将配置的读写操作递交给相应的ConfigurationProvider来完成而ConfigurationSection则将委托自己的根配置节来完成读写配置的操作这样的策略体现在如下所示的代码中。 [1] ForEach是为了让代码尽量精练而为类型IEnumerableT定义的扩展方法在后续章节中我们会经常使用到它。 相关文章 ASP.NET Core 1.0 入门——了解一个空项目ASP.NET Core 1.0 部署 HTTPS .NET Framework 4.5.1.NET Core 1.0、ASP.NET Core 1.0和EF Core 1.0简介云服务器下ASP.NET Core 1.0环境搭建包含mono与coreclr使用VS Code开发ASP.NET Core 应用程序dotnet run是如何启动asp.net core站点的ASP.NET Core提供模块化Middleware组件“dotnet restore和dotnet run都做了些什么探秘 dotnet run 如何运行 .NET Core 应用程序.NET Portability Analyzer 已开源ASP.NET Core的配置1读取配置信息 原文地址http://www.cnblogs.com/artech/p/asp-net-core-config-02.html .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
