.NET Core采用的全新配置系统[9]: 为什么针对XML的支持不够好?如何改进?

物理文件是我们最常用到的原始配置的载体,最佳的配置文件格式主要由三种,它们分别是JSON、XML和INI,对应的配置源类型分别是JsonConfigurationSource、XmlConfigurationSource和IniConfigurationSource。但是对于.NET Core的配置系统来说,我们习以为常的XML反倒不是理想的配置源,至少和JSON比较起来,它具有一个先天不足的劣势,那就是针对集合数据结构的支持不如人意。[ 本文已经同步到《ASP.NET Core框架揭秘》之中]

一、为什么针对集合的配置难以通过优雅的XML来表示

在《配置模型设计详解》一文中我们对配置模型的设计和实现进行了详细介绍。在此文中我们说应用中的配置体现为一种树形化的层次结构,所我将它称为“配置树”,具体的配置数据通过配置树的“叶子节点”承载。当配置数据从不同的来源加载之后都会转换成一个字典,我将其称为“配置字典”。为了让“配置字典”能够存储“配置树”的所有数据和自身结构,我们需要在配置字典中存储所有叶子节点,叶子节点的路径和值将直接作为字典元素的Key和Value。由于字典的Key是唯一的,这就要求配置树中的每一个节点必须具有唯一的路径。XmlConfigurationSource/XmlConfigurationProvider不能很好地支持集合数据结构的问题就出现在这里。

   1: public class Profile
   2: {

   3:     public Gender         Gender { get; set; }

   4:     public int            Age { get; set; }

   5:     public ContactInfo    ContactInfo { get; set; }

   6: }

   7:  

   8: public class ContactInfo

   9: {

  10:     public string EmailAddress { get; set; }

  11:     public string PhoneNo { get; set; }

  12: }

  13:  

  14: public enum Gender

  15: {

  16:     Male,

  17:     Female

  18: }

举个简单的例子,假设需要采用XML来表示一个Profile对象的集合(Profile的类型具有如上所示的定义),那么我们很自然地会采用如下的结构。

   1: <Profiles>
   2:   <Profile Gender="Male" Age="18">

   3:     <ContactInfo EmailAddress ="[email protected]" PhoneNo="123"/>

   4:   </Profile>

   5:   <Profile Gender="Male" Age="25">

   6:     <ContactInfo EmailAddress ="[email protected]" PhoneNo="456"/>

   7:   </Profile>

   8:   <Profile Gender="Male" Age="40">

   9:     <ContactInfo EmailAddress ="[email protected]" PhoneNo="789"/>

  10: </Profile>

对于这段XML结构,XmlConfigurationProvider会采用“简单粗暴”的方式将它映射为如下所示的“配置树”。由于这棵树直接将XML元素的名称作为配置节点名称,所以三个Profile对象在这棵树中的根节点都以“Profile”命名,毫无疑问,这颗树将不能使用字典来表示,因为它不能保证所有的节点都具有不同的路径。

二、按照配置树的要求对XML结构稍作转换

之所以XML不能像JSON格式那样可以以一种很自然的形式表示集合或者数组,是因为后者对这两种数据类型提供了明确的定义方式(采用中括号定义),但是XML只有子元素的概念,我们不能确定它的子元素是否是一个集合。如果做这样一个假设:如果同一个XML元素下的所有子元素都具有相同的名称,那么我们可以将其视为集合。根据这么一个假设,我们对XmlConfigurationSource略加改造就可以解决XML难以表示集合数据结构的问题。

我们通过派生XmlConfigurationSource创建一个新的ConfigurationSource类型,姑且将其命名为ExtendedXmlConfigurationSource。XmlConfigurationSource提供的ConfigurationProvdier类型为ExtendedXmlConfigurationProvider,它派生于XmlConfigurationProvider。在重写的Load方法中,ExtendedXmlConfigurationProvider通过对原始的XML结构进行相应的改动,从而让原本不合法的XML(XML元素具有相同的名称)可以转换成一个针对集合的配置字典 。下图展示了XML结构转换采用的规则和步骤。

如上图所示,针对集合对原始XML所作的结构转换由两个步骤组成。第一步为表示集合元素的XML元素添加一个名为“append_index”的属性(Attribute),我们采用零基索引作为该属性的值。第二步会根据第一步转换的结果创建一个新的XML,同名的集合元素(比如<profile>)将会根据添加的索引值从新命名(比如<profile_index_0>)。毫无疑问,转换后的这个XML可以很好地表示一个集合对象。如下所示的是ExtendedXmlConfigurationProvider的定义,上述的这个转换逻辑体现在重写的Load方法中。

   1: public class ExtendedXmlConfigurationProvider : XmlConfigurationProvider
   2: {

   3:    public ExtendedXmlConfigurationProvider(XmlConfigurationSource source) : base(source)

   4:     {}

   5:  

   6:     public override void Load(Stream stream)

   7:     {

   8:         //加载源文件并创建一个XmlDocument        

   9:         XmlDocument sourceDoc = new XmlDocument();

  10:         sourceDoc.Load(stream);

  11:  

  12:         //添加索引

  13:         this.AddIndexes(sourceDoc.DocumentElement);

  14:  

  15:         //根据添加的索引创建一个新的XmlDocument

  16:         XmlDocument newDoc = new XmlDocument();

  17:         XmlElement documentElement = newDoc.CreateElement(sourceDoc.DocumentElement.Name);

  18:         newDoc.AppendChild(documentElement);

  19:  

  20:         foreach (XmlElement element in sourceDoc.DocumentElement.ChildNodes)

  21:         {

  22:             this.Rebuild(element, documentElement, 

  23:                 name => newDoc.CreateElement(name));

  24:         }

  25:  

  26:         //根据新的XmlDocument初始化配置字典

  27:         using (Stream newStream = new MemoryStream())

  28:         {

  29:             using (XmlWriter writer = XmlWriter.Create(newStream))

  30:             {

  31:                 newDoc.WriteTo(writer);

  32:             }

  33:             newStream.Position = 0;

  34:             base.Load(newStream);

  35:         }

  36:     }

  37:  

  38:     private void AddIndexes(XmlElement element)

  39:     {

  40:         if (element.ChildNodes.OfType<XmlElement>().Count() > 1)

  41:         {

  42:             if (element.ChildNodes.OfType<XmlElement>().GroupBy(it => it.Name).Count() == 1)

  43:             {

  44:                 int index = 0;

  45:                 foreach (XmlElement subElement in element.ChildNodes)

  46:                 {

  47:                     subElement.SetAttribute("append_index", (index++).ToString());

  48:                     AddIndexes(subElement);

  49:                 }

  50:             }

  51:         }

  52:     }

  53:  

  54:     private void Rebuild(XmlElement source, XmlElement destParent, Func<string, XmlElement> creator)

  55:     {

  56:         string index = source.GetAttribute("append_index");

  57:         string elementName = string.IsNullOrEmpty(index) ? source.Name : $"{source.Name}_index_{index}";

  58:         XmlElement element = creator(elementName);

  59:         destParent.AppendChild(element);

  60:         foreach (XmlAttribute attribute in source.Attributes)

  61:         {

  62:             if (attribute.Name != "append_index")

  63:             {

  64:                 element.SetAttribute(attribute.Name, attribute.Value);

  65:             }

  66:         }

  67:  

  68:         foreach (XmlElement subElement in source.ChildNodes)

  69:         {

  70:             Rebuild(subElement, element, creator);

  71:         }

  72:     }

  73: }

时间: 2024-09-29 08:11:23

.NET Core采用的全新配置系统[9]: 为什么针对XML的支持不够好?如何改进?的相关文章

.NET Core采用的全新配置系统[10]: 配置的同步机制是如何实现的?

配置的同步涉及到两个方面:第一,对原始的配置文件实施监控并在其发生变化之后从新加载配置:第二,配置重新加载之后及时通知应用程序进而使后者能够使用最新的配置.要了解配置同步机制的实现原理,先得从认识一个名为ConfigurationReloadToken的类型开始. [ 本文已经同步到<ASP.NET Core框架揭秘>之中] 目录一.从ConfigurationReloadToken说起二.Configuration对象与配置文件的同步三.应用重新加载的配置四.同步流程总结 一.从Config

.NET Core采用的全新配置系统[3]: “Options模式”下的配置是如何绑定为Options对象

配置的原子结构就是单纯的键值对,并且键和值都是字符串,但是在真正的项目开发中我们一般不会单纯地以键值对的形式来使用配置.值得推荐的做法就是采用<.NET Core采用的全新配置系统[1]: 读取配置数据>最后演示的方式将相关的配置定义成一个Options类型,并采用与类型定义想匹配的结构来定义原始的配置,这样就能利用它们之间的映射关系将读取的配置数据绑定为Options对象,我们将这种编程模式称为“Options模式”. [ 本文已经同步到<ASP.NET Core框架揭秘>之中]

.NET Core采用的全新配置系统[2]: 配置模型设计详解

在<.NET Core采用的全新配置系统[1]: 读取配置数据>中,我们通过实例的方式演示了几种典型的配置读取方式,其主要目的在于使读者朋友们从编程的角度对.NET Core的这个全新的配置系统具有一个大体上的认识,接下来我们从设计的维度来重写认识它.通过上面演示的实例我们知道,配置的编程模型涉及到三个核心对象,它们分别是Configuration.ConfigurationSource和ConfigurationBuilder.如果从设计层面来审视这个配置系统,还缺少另一个名为Configu

.NET Core采用的全新配置系统[5]: 聊聊默认支持的各种配置源[内存变量,环境变量和命令行参数]

较之传统通过App.config和Web.config这两个XML文件承载的配置系统,.NET Core采用的这个全新的配置模型的最大一个优势就是针对多种不同配置源的支持.我们可以将内存变量.命令行参数.环境变量和物理文件作为原始配置数据的来源,如果采用物理文件作为配置源,我们可以选择不同的格式(比如XML.JSON和INI等) .如果这些默认支持的配置源形式还不能满足你的需求,我们还可以通过注册自定义ConfigurationSource的方式将其他形式数据作为我们的配置来源. [ 本文已经同

.NET Core采用的全新配置系统[6]: 深入了解三种针对文件(JSON、XML与INI)的配置源

物理文件是我们最常用到的原始配置的载体,最佳的配置文件格式主要由三种,它们分别是JSON.XML和INI,对应的配置源类型分别是JsonConfigurationSource.XmlConfigurationSource和IniConfigurationSource. [ 本文已经同步到<ASP.NET Core框架揭秘>之中] 目录一.FileConfigurationSource  & FileConfigurationProvider 二.JsonConfigurationSou

.NET Core采用的全新配置系统[4]: &ldquo;Options模式&rdquo;下各种类型的Options对象是如何绑定的?

旨在生成Options对象的配置绑定实现在IConfiguration接口的扩展方法Bind上.配置绑定的目标类型可以是一个简单的基元类型,也可以是一个自定义数据类型,还可以是一个数组.集合或者字典类型.通过前面的介绍我们知道ConfigurationProvider将原始的配置数据读取出来后会将其转成Key和Value均为字符串的数据字典,那么针对这些完全不同的目标类型,原始的配置数据如何通过数据字典的形式来体现呢? [ 本文已经同步到<ASP.NET Core框架揭秘>之中] 目录一.绑定

.NET Core采用的全新配置系统[7]: 将配置保存在数据库中

我们在<聊聊默认支持的各种配置源>和<深入了解三种针对文件(JSON.XML与INI)的配置源>对配置模型中默认提供的各种ConfigurationSource进行了深入详尽的介绍,如果它们依然不能满足项目中的配置需求,我们可以还可以通过自定义ConfigurationProvider来支持我们希望的配置来源.就配置数据的持久化方式来说,将培植存储在数据库中应该是一种非常常见的方式,接下来我们就是创建一个针对数据库的ConfigurationSource,它采用最新的Entity

.NET Core采用的全新配置系统[8]: 如何实现配置与源文件的同步

配置的同步涉及到两个方面:第一,对原始的配置文件实施监控并在其发生变化之后从新加载配置:第二,配置重新加载之后及时通知应用程序进而使后者能够使用最新的配置.接下来我们利用一个简单的.NET Core控制台应用来演示针对文件的配置会涉及到数据同步的问题,我们希望应用能够对原始配置文件实施监控,并在文件内容发生改变的时候从新加载并应用新的配置.针对JSON文件的配置源通过JsonConfigurationSource类型来表示,该类型定义在“Microsoft.Extensions.Configur

MySQL中间件之ProxySQL(3):多层配置系统

1.ProxySQL中的库 使用ProxySQL的Admin管理接口连上ProxySQL,可查看ProxySQL拥有的库. mysql -uadmin -padmin -h127.0.0.1 -P6032 --prompt 'admin> ' admin> show databases; +-----+---------------+-------------------------------------+ | seq | name | file | +-----+-------------