.NET配置文件解析过程详解(二)

.NET配置文件解析过程详解(二)

在上一篇文章的基础上，我们继续我们的解析
以machine.config文件内部定义的部分section handler为例，来分析各个配置节点的工厂是如何产生具体程序对象的。

<configuration>下的section handlers

IgnoreSectionHandler

在machine.config的<configSections>中有以下section是不在sectiongroup里的，换句话说这些section对应的xml节点位于配置文件根节点configuration的次级。

在这里面，runtime, remoting等section对应的handler类是IgnoreSectionHandler，难道他们用同一种工厂就可以创造出各自需要的对象？当然不是，看看SDK里对IgnoreSectionHandler的定义：

配置系统会彻底分析配置文件以收集配置信息，并且当遇到在 <configSections> 元素节中无相应项的配置节时将引发异常。IgnoreSectionHandler 为其他系统所读取的节提供节处理程序，以防止配置文件分析异常。

反编译IgnoreSectionHandler类的Create方法的内容为：

public virtual object Create(object parent, object configContext, XmlNode section)

{

return null;

}

因此，我们发现IgnoreSectionHandler真的是什么也不做，只是为了取得对应配置节在配置文件中的合法地位，是不是有点像办个户口，占个位置啊？SDK里所说的其他系统是什么意思呢？既然IgnoreSectionHandler返回的是个null，那其系统是怎么来通过Getconfig来获得需要的配置信息呢？答案是抛弃默认的GetConfig方法，重头再来。我们以remoting为例，看看他怎么来获得配置文件里的信息的。在命名空间下System.Runtime.Remoting下有个RemotingConfiguration类，以公共静态方法Configure接收一个配置文件名，并将解析过程交给一个handler类 RemotingConfigHandler，这个handler并没有实现IConfigurationSectionHandler接口。RemotingConfigHandler则将实际的事务交给类RemotingXmlConfigFileData，而RemotingXmlConfigFileData将XML文件的解析过程交给RemotingXmlConfigFileParser来处理。

string text2;

RemotingXmlConfigFileData data1 = new RemotingXmlConfigFileData();

ConfigTreeParser parser1 = new ConfigTreeParser();

ConfigNode node1 = parser1.Parse(filename, "/configuration/system.runtime.remoting");

由此可见,remoting部分是自己重新打造了配置文件的解析过程。为什么会这样呢？为什么结构严谨的.net架构下会允许这样一种不统一的操作呢？这是不是一种bad的设计呢？这就要涉及到system.dll和mscorlib.dll两个组件之间的关系了。System.dll引用了mscorlib.dll，也就是说System.dll依赖于组件mscorlib.dll，通用配置框架的外观类ConfigurationSettings处于system.dll的System.Configuration命名空间下，而RemotingConfigHandler位于mscorlib，这样的结构就不能让RemotingConfigHandler实现System.dll里的IConfigurationSectionHandler接口了，既然某些配置程序的处理在ConfigurationSettings之前，那么我们对于“前辈们”的位置，我们必须认为它是合法的，然后在其位置上放一个牌子”occupied” -- IgnoreSectionHandler ，以通过验证。这种设计模式我认为确实值得商榷，以我目前的了解，从模式角度讲，觉得不是很合理。

NameValueSectionHandler

返回健值对集合对象，ConfigurationSettings.AppSettings就是由NameValueSectionHandler返回的ReadOnlyNameValueCollection。为什么是readonly?原因当然不只是配置文件是只读的那么简单，因为在上一篇文章中，我有谈到解析后的对象会存在hashtable中，一旦程序请求同一个tagkey就返回同一对象，也就是解析一次，如果有删除操作，除非重启程序，否则是无法读到完整的原始配置信息的，这就涉及到我们在写自定义配置节及其hadler时要注意的一个地方，如果返回一个hashtable时，如果有删除和修改操作将会在应用程序生命周期内有效。我曾经写过一个项目，从配置文件返回一个hashtable储存的对象集合，为了提高效率，我会将表中某些对象remove掉，结果导致第一次运行一个页面和后面几次运行一个页面效果不一样的情况，害我费了很多精力找出原因。在上一篇文章中讲过配置文件的继承，但究竟在细节上是怎么来实现的呢？我们从section的继承上寻找答案。实现配置信息继承的代码为：

ReadOnlyNameValueCollection collection1;

if (parent == null)

{

collection1 = new ReadOnlyNameValueCollection(new CaseInsensitiveHashCodeProvider(CultureInfo.InvariantCulture), new CaseInsensitiveComparer(CultureInfo.InvariantCulture));

}

else

{

ReadOnlyNameValueCollection collection2 = (ReadOnlyNameValueCollection) parent;

collection1 = new ReadOnlyNameValueCollection(collection2);

}

NameValueSectionHandler对节点的具体分析代码为：

if (node1.Name == "add")

{

string text1 = HandlerBase.RemoveRequiredAttribute(node1, keyAttriuteName);

string text2 = HandlerBase.RemoveRequiredAttribute(node1, valueAttributeName, true);

HandlerBase.CheckForUnrecognizedAttributes(node1);

collection1[text1] = text2;

continue;

}

if (node1.Name == "remove")

{

string text3 = HandlerBase.RemoveRequiredAttribute(node1, keyAttriuteName);

HandlerBase.CheckForUnrecognizedAttributes(node1);

collection1.Remove(text3);

continue;

}

if (node1.Name.Equals("clear"))

{

HandlerBase.CheckForUnrecognizedAttributes(node1);

collection1.Clear();

continue;

}

NameValueFileSectionHandler

NameValueFileSectionHandler在SDK 中并没有相应的文档。我发现有个特点，就是很多人把这个类当成NameValueSectionHandler用，这样用似乎也没出什么问题，难道ms写了两个一样的类？非也。其实，NameValueFileSectionHandler 可以说是NameValueSectionHandler的一个升级版，升就升在 “File”上！

我们经常抱怨配置文件越来越大了，即使是级联格式，找起东西来还是眼花，其实.net配置文件体系给我们提供了一种内置的操作来实现多个配置文件，那就是NameValueFileSectionHandler。NameValueFileSectionHandler也是返回ReadOnlyNameValueCollection。我们来看看具体的实现代码：

object obj1 = parent;

XmlNode node1 = section.Attributes.RemoveNamedItem("file");

obj1 = NameValueSectionHandler.CreateStatic(obj1, section);

if ((node1 == null) || (node1.Value.Length == 0))

{

return obj1;

}

如果该section没有file这个属性，那么其处理方式就跟NameValueSectionHandler一样，NameValueFileSectionHandler调用NameValueSectionHandler的解析过程来取得对象。如果有file这个属性NameValueFileSectionHandler就去当前目录下或该文件的绝对路径去找到这个文件：

string text3 = Path.GetDirectoryName(node2.Filename);

string text4 = Path.Combine(text3, text1);

对找到的文件，当然是xml解析了，取根节点作为section分析节点。

ConfigXmlDocument document1 = new ConfigXmlDocument();

try

{

document1.Load(text4);

}

然后将新去到的xml节点当成section节点一样用NameValueSectionHandler解析。这样就把要写在配置文件中的name/value集合放到另外一个xml文件里去了，这样就实现了配置文件的分割，这在配置文件有很多键值对的系统中应该是比较有用的。

return NameValueSectionHandler.CreateStatic(obj1, document1.DocumentElement);

    DictionarySectionHandler
     NameValueSectionHandler和DictionarySectionHandler在定义配置文件的内容形式上是一样的，都是用<key><value>来设置内容的。不同的是DictionarySectionHandler比较封闭，不具有弹性，不像NameValueSectionHandler还提供给fieldhandler调用，”key”,”value”这些字符也是在属性里写死的，而且返回到C#中的类不太一样，DictionarySectionHandler返回的是一个hashtable，但还是字符串的键值对。

   SingleTagSectionHandler

     最简单的就是他了，就是把属性的键值对作为hashtable的键值对返回。

foreach (XmlAttribute attribute1 in section.Attributes)

{

hashtable1[attribute1.Name] = attribute1.Value;

}

return hashtable1;

在后面的文章中，我将深入<sectionGroup name="system.web">进行研究和分析。

posted on 2005-12-04 20:23 sharpedge 阅读(5391) 评论(6) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部