企业库EntLib初识(3)--配置管理应用程序块ConfigurationApplicationBlock

偷了几天懒，今天怎么也得继续写的了，总不能让才喊出来没几天的口号告终吧。嘿～
今天我们回过头看一下在DAAB探讨中提到的配置管理应用程序块Configuration Application Block。配置管理应用程序块是企业库中的最低层，企业库的其它应用程序块都依赖于它。那为什么会依赖于它呢？现在提倡配置驱动的应用开发，就是把应用中客观存在的大量配置信息与程序代码作分离。既然微软都运用这种机制去开发企业库的框架(也不能排除往后版本会引入新机制)，我们短期内也不必论证实它的价值了。费话少说，我们就开始探讨一下配置管理应用程序块吧！

首先，我们了解一下配置管理应用程序块为我们带来什么。

从前，我们常规地会把应用程序的配置信息通过三种方式去保存：配置文件（ini文件或者XML文件）、注册表和数据库。三种方式都有各自适当的运用场合，而配置管理应用程序块的出现并不是否决了这三种方式，而是为我们提供了更好地通过这三种方式去实现应用程序配置管理的解决方案。因为配置信息与代码逻辑是分离的，所以我们可以更灵活地选择配置信息的解决方案。甚于可以通过简单的配置，不需要改写代码便可以从一种方式改变为另一种方式。

另外，配置管理应用程序块给我们提供了简单的读写配置信息的接口。让我们简单地调用读写配置信息的方法便可以操作配置信息，而无需考虑各种物理存储结构的差异性。

最后就是“提供一种允许自定义存储位置和配置设置的运行时表示的可扩展模型”。这个扩展性让我们以后再探讨吧，至少现阶段微软提供的已经够用了。

然后，认识配置管理应用程序块的主要对象。

配置管理应用程序块通过存储提供程序和转换器将配置数据的读写能力与物理存储结节相分离。存储提供程序是读写特定物理存储（包括XML和数据库）的对象，而转换器的功能是使配置数据在应用程序期望的数据格式（如对象、数组等）与物理存储要求的格式（如XML和数据表）间进行转换。

需要特别注意的是在配置管理应用程序块的解决方案中，配置数据被分离成配置元数据（metadata）和配置数据具体内容，分别保存在不同的配置文件中。配置元数据分别定义了存储提供程序、转换器，并在其中指定配置数据具体内容的路径，是否要加密等信息。配置数据具体内容则存放应用程序真正的配置数据内容。

具体地说，我们通常把配置元数据存放在App.config或Web.config文件中（定义存储提供程序和转换器），关于这个配置文件的内容已经超出我们的讨论范围，请您查看相关书籍作了解，在这里我们只需知道它是以XML格式保存数据就足够了。关键代码段如下：

<configurationSections>

<configurationSection name="dataConfiguration" encrypt="false">

<storageProvider xsi:type="XmlFileStorageProviderData" name="XML File Storage Provider" path="dataConfiguration.config" />

<dataTransformer xsi:type="XmlSerializerTransformerData" name="Xml Serializer Transformer">

<includeTypes />

</dataTransformer>

</configurationSection>

</configurationSections>

我们从最外层开始分析一下上边代码：

最外层<configurationSections>为配置节（或者叫配置区）的集合，顾名思义里面由N个configurationSection（配置节）组成。企业库里面每个应用程序块都有各自的配置节。当然我也可以在其中扩展自己配置块。

每个configurationSection表示一个配置节。它的name属性为配置节的名称，这个属性为我们提供了配置数据与程序代码作交互的标识。Encrypt属性表示对具体配置内容是否进行加密。但需要注意的是对具体配置内容做加密处理，并不能简单地把属性设置为True，这个问题还是以后再找机会跟大家详细探讨吧。

storageProvider定义了上下文配置节中的存储提供程序。它的type属性指定了存储提供程序的类型，分别可以是XML、SQL数据库等。到这里我们不能全部记住它们并不重要，只要用之前提到的企业库配置工具就可以从下拉列表框中选取了。取了type和name属性以外，其它的附加属性可能会因为type的选择而不一样，但附加属性的目的都是为了指定具体配置内容的“路径”，这里就不一一阐述了。例子中的path属性指的是type选择为XML后具体配置内容所存放的XML文件的路径。

dataTransformer定义了上下文配置节中的转换器。它跟storageProvider组成配置元数据的核心部分。转换器的作用在前面已经讨论过了，而且属性跟storageProvider也相似，我们就不再罗嗦了。

需要指出的是，上边的配置元数据我们很少会自己敲代码，因为微软已经为我们提供了一个非常不错的企业库配置工具Enterprise Library Configuration。使用它，我们可以方便快捷地完成所有应用程序块的相关配置工作并把配置元数据保存到App.config或Web.config文件中。

最后，来简单地体验一下配置管理应用程序块的使用。

第一步，配置好配置元数据（必须配置好存储提供程序和转换器）。这里一定要搞清楚概念，配置管理应用程序块本身也是要配置好才能工作的，而Enterprise Library Configuration是微软提供让我们可以快速做好配置工作的工具。关于Enterprise Library Configuration的使用方法请参照DAAB的配置工作：http://ryu666.cnblogs.com/archive/2005/11/07/270350.html

第二步，进行读/写操作。我们知道配置管理应用程序块即可以读写值类型的对象又可以读写引用类型的对象，只要对象是可序列化就行了。

值类型对象的写操作请看下边例程：

string serverName=”MyServer”;

ConfigurationManager.WriteConfiguration(“SalesData”,servername);

这个不用多说明了吧，一眼就能看得出配置管理应用程序块的写配置操作是通过ConfigurationManager对象的WriteConfiguration静态方法来实现的，参数就是需要写入的配置节名称(name属性)和需要写入的内容，就那么简单。引用类型对象的写操作其实也是一样的，只是需要先定义写入的对象类，然后给对象赋值，最后才写入。

需要注意两点：其一，整个配置节的数据将被覆盖。其二，配置元数据中必需包含写入的配置节的定义。

我们再看看读配置数据。同样我们也拿读值类型对象来做例子，读引用类型对象也是雷同的。

string serverName = (string)ConfigurationManager.GetConfiguration("SalesData");

由此可见，我们一行代码便完成了配置数据的读取。复杂的实现逻辑已经被企业库封装起来了，我们需要做的只是简单配置。

因为昨天写了一半睡着了，所以这篇东西分了两天来写，再加上本人的认识有限，描述不当之处望前辈们批评指正。到此就搁笔了，谢谢阅读。