ConfigurationFile类代码分析
大致介绍下configuration类库中几个首先出场的角色ConfigurationManager ConfigurationContext ConfigurationBuilder这三个类，可以看作是三个不同层次上的包装器(wrapper)，他们之间通过责任链模式实现彼此衔接的(在1.1中体现的尤为明显)
ConfigurationFile configurationSettings configSections这些才是真正解析配置文件的地方。Transformer、 Storage这些里面也涉及一些重要的东东，以后再介绍(我也才把1.1版下载来不到1小时还没有仔细看和1.0中的区别^_^)
至于配置文件监视器这块，以后专门单独介绍它，好了开工吧
整体的感觉1.1的结构比起1.0来更为清晰，至少像我这种菜鸟来读疑惑不是太多了
Enlib1.0中
ConfigurationFile类，构造器
代码如下
public ConfigurationFile() : this(null) {
}
public ConfigurationFile(ConfigurationFile parent) {
this.results = new Hashtable();
this.parent = parent;
this.unevaluatedSections = new Hashtable();
}
ConfigurationBuilder类，LoadMetaConfiguration方法代码如下
private void LoadMetaConfiguration(string configurationFile) {
configFile = new ConfigurationFile();
string machineFilename = MachineConfigurationFile;
// make sure we don't load the machine file twice
if (string.Compare(configurationFile, machineFilename, true, CultureInfo.InvariantCulture) != 0) {
ConfigurationFile machineConfigFile = new ConfigurationFile();
bool machineFileExists = machineConfigFile.Load(machineFilename);
if (machineFileExists) {
configFile = new ConfigurationFile(machineConfigFile);
}
}
当初看到ConfigurationBuilder类中LoadMetaConfiguration()方法时就觉得写得有些不妥，也一直没搞懂在configuration类库中它预加载并解析machine.config文件有什么意义。
看了Enlib1.1中的代码，我似乎找到了答案
ConfigurationFile类，构造器代码如下：
public ConfigurationFile(string configurationFile, ConfigurationFile parent)
{
SetConfigurationFileName(configurationFile);
this.parent = parent;
this.configurationSettings = null;
}
GetConfig方法代码如下：
public object GetConfig(string configKey)
{
if (this.configurationSettings != null)
{
return this.configurationSettings;
}
ConfigurationSettingsLoader handler = new ConfigurationSettingsLoader();
this.configurationSettings = handler.Build(this.configurationFile);
if (this.configurationSettings == null)
{
// try parent
if (parent != null)
{
this.configurationSettings = handler.Build(parent.configurationFile);
}
}
return this.configurationSettings;
}
ConfigurationBuilder类，LoadMetaConfiguration方法代码如下
private void LoadMetaConfiguration(string configurationFile)
{
configFile = new ConfigurationFile(configurationFile, null);
string machineFilename = MachineConfigurationFile;
// make sure we don't load the machine file twice
if (string.Compare(configurationFile, machineFilename, true, CultureInfo.InvariantCulture) != 0)
{
ConfigurationFile machineConfigFile = new ConfigurationFile(machineFilename, null);
configFile = new ConfigurationFile(configurationFile, machineConfigFile);
}
CreateMetaConfigChangeWatcher();
this.currentConfigFileName = configurationFile;
InitializeConfiguration(ReadMetaConfiguration());
}
我之所以把LoadMetaConfiguration()这个方法罗列出来，原因有两点1、仔细看了这两个版本中ConfigurationFile类不难发现它们在整个配置库结构体系中的任务截然不同而实现目标却是大同小异。作者却能将其重构的如些完美，不感叹…(难怪朋友说我再过五年也难做到这一步!)2、因为一直觉得它写的有点不好：)也可能是我井底之蛙吧，有待于在其后继版本中证实，暂不指出了
在1.0版本中，不难发现ConfigurationFile类的大致作用是初步解析两个配置文件machine.config和yourApp.config并起到一个缓冲的功能。里面用到一大堆工具方法终于把那两个文件做了初步的解析。当时看了一直纳闷XmlReader无非提供对 XML 数据进行快速、非缓存、只进访问的读取。作者为什么不用XPath来实现省得让偶分析了半天冗长的代码才发现杀鸡用了牛刀^-^
仔细看完1.1中ConfigurationFile类后你会发现两个版本中，几个解析配置文件类的所完成的任务也做了很大的调整，而且它们的衔接方式也完全不同了。不过读起来更加简洁清晰：)。这块我会在后继代码阅读笔记中一一介绍并整理出组织结构图。