.NET Core全新的配置管理[共9篇]
提到“配置”二字，我想绝大部分.NET开发人员脑海中会立马浮现出两个特殊文件的身影，那就是我们再熟悉不过的app.config和web.config，多年以来我们已经习惯了将结构化的配置信息定义在这两个文件之中。到了.NET Core的时候，很多我们习以为常的东西都发生了改变，其中也包括定义配置的方式。总的来说，新的配置系统显得更加轻量级，并且具有更好的扩展性，其最大的特点就是支持多样化的数据源。我们可以采用内存的变量作为配置的数据源，也可以直接配置定义在持久化的文件甚至数据库中。
提到“配置”二字，我想绝大部分.NET开发人员脑海中会立马浮现出两个特殊文件的身影，那就是我们再熟悉不过的app.config和web.config，多年以来我们已经习惯了将结构化的配置信息定义在这两个文件之中。到了.NET Core的时候，很多我们习以为常的东西都发生了改变，其中也包括定义配置的方式。总的来说，新的配置系统显得更加轻量级，并且具有更好的扩展性，其最大的特点就是支持多样化的数据源。我们可以采用内存的变量作为配置的数据源，也可以直接配置定义在持久化的文件甚至数据库中。
目录
一、读取配置信息
二、配置模型详解
三、将配置绑定为各种类型的对象
四、Options模型背后的故事
五、多样性的配置来源：内存变量、环境变量和命令行开关
六、多样性的配置来源：JOSN文件、XML文件 和INI文件
七、多样性的配置来源：自定义ConfiguationProvider支持其他配置源
八、配置的同步[实例篇]
九、配置的同步[设计篇]
一、读取配置信息
由于很多人都不曾接触过这个采用全新设计的配置系统，为了让大家对此有一个感官的认识，我们先从编程的角度对它作一个初体验。针对配置的API涉及三个对象，它们分别是Configuration、ConfigurationBuilder和ConfigurationProvider，配置模型中具有相应的接口来表示它们。这三个对象之间的关系很清晰，Configuration对象承载着在编程过程中使用的配置信息，ConfigurationProvider则是配置信息原始数据源的提供者，两者之间沟通由ConfigurationBuilder来完成，它利用ConfigurationProvider提取源数据将其转换为Configuration对象。[阅读全文]
二、配置模型详解
在《读取配置信息》一文中我们以实例演示的方式介绍了几种读取配置的几种方式，其中涉及到三个重要的对象，它们分别是承载结构化配置信息的Configuration，提供原始配置源数据的ConfigurationProvider，以及作为“中间人”的ConfigurationBuilder。[阅读全文]
三、将配置绑定为各种类型的对象
出于编程上的便利，我们通常不会直接利用ConfigurationBuilder创建的Configuration对象读取某个单一配置项的值，而是倾向于将一组相关的配置绑定为一个对象，我们将后者称为Options对象。配置在逻辑上体现为一个具有层次化的配置树，对于一个Options对象来说，如果我们将其数据成员视为其子节点，那么Options对象同样具有一个层次化属性结构，所以Options对象和配置在数据结构层面并没有本质的差异。如果Options类型的数据成员定义与配置的结构具有一一匹配关系，那么将后者绑定为一个对应类型的Options对象是一件很容易的事情，我们本节重点介绍的ConfigurationBinder就是利用这样的原理实现了结构化配置向数据对象的自动绑定。[阅读全文]
四、Options模型背后的故事
整个Options模型以两个注册到ServiceCollection的服务为核心，这两个服务对应的服务接口分别是IOptions <TOptions>和IConfigureOptions<TOptions>，前者直接提供最终绑定了配置数据的Options对象，后者则在Options对象返回之前对它实施相应的初始化工作。这个两个服务分别通过扩展方法AddOptions和Configure方法注册到指定的ServiceCollection之中，服务的真实类型分别是OptionsManager<TOptions>和ConfigureFromConfigurationOptions<TOptions>，后者派生于ConfigureOptions<TOptions>。[阅读全文]
五、多样性的配置来源：内存变量、环境变量和命令行开关
较之传统通过App.config和Web.config这两个XML文件承载的配置系统，ASP.NET Core采用的这个全新的配置模型的最大一个优势就是针对多种不同配置源的支持。我们可以将内存变量、命令行参数、环境变量和物理文件作为原始配置数据的来源，如果采用物理文件作为配置源，我们可以选择不同的格式，比如XML、JSON和INI等。本章涉及三种配置来源，即内存变量、环境变量和命令行开关。[阅读全文]
六、多样性的配置来源：JSON文件、XML文件 和INI文件
我们在本篇文章中会介绍三种针对物理文件的ConfiguationProvider，它们分别是针对JSON文件的JsonConfiguationProvider，针对XML文件的XmlConfiguationProvider以及针对INI文件的IniConfiguationProvider。对于这三种文件类型（JSON、XML和INI）来说，JSON能够采用简单直观的格式表示具有不同结构的数据，所以它是作为配置最好的选择。。[阅读全文]
七、多样性的配置来源：自定义ConfiguationProvider支持其他配置源
我们对配置模型中默认提供的各种ConfigurationProvider进行了深入详尽的介绍，如果它们依然不能满足项目中的配置需求，我们可以还可以通过自定义ConfigurationProvider来支持我们希望的配置来源。就配置数据的持久化方式来说，将配置存储在数据库中应该是一种非常常见的方式，接下来我们就是创建一个针对数据库的ConfigurationProvider，它采用最新的Entity Framework 7来完成数据库的存取操作。[阅读全文]
八、配置的同步[实例篇]
ConfigurationBuilder在生成以Configuration对象的时候会利用注册其中的ConfigurationProvider加载原始的配置数据，那么一旦配置源中的数据发生变化，应用程序中的使用的配置信息如何与之同步呢？如果需要在应用程序中实现对配置信息的实施同步，就需要对原始配置数据的进行监控，并在数据改变的时候重新加载配置数据。除此之外，重新加载的配置需要应用到程序中，我们必然需要一种通知机制。为了让读者朋友们对配置同步机制在具体项目中的应用有个感官认识，我们先通过一个简单的实例来演示如何实现配置数据的实时同步。我们采用一个INI文件作为配置源，通过实施监控这个文件第一时间感知到文件内容的变换。一旦原始配置文件的内容发生改变，应用程序将重新加载配置，并通过注册的回掉操作应用新的配置。[阅读全文]
九、配置的同步[设计篇]
本节所谓的“配置同步”主要体现在两个方面：其一，如何监控配置源并在其变化的时候自动加载其数据，其目的是让应用中通过Configuration对象承载的配置与配置源的数据同步；其二、当Configuration对象承载的配置放生变换的时候如何向应用程序发送通知，最终让应用程序使用最新的配置。[阅读全文]
