[EntLib]微软企业库5.0 学习之路——第八步、使用Configuration Setting模块等多种方式分类管理企业库配置信息

      在介绍完企业库几个常用模块后，我今天要对企业库的配置文件进行处理，缘由是我打开web.config想进行一些配置的时候发现web.config已经变的异常的臃肿（大量的企业库配置信息充斥其中），所以决定写这篇关于Configuration Setting模块等其他方式分类管理企业库配置信息的文章。

在ASP.NET4中微软就帮我们优化过了web.config，给了我们一个干净的web.config（将原来需要通过web.config注册的程序集、ASP.NET标签和handler等都移至machine.config中）这样大大方便了我们开发人员。

虽然我们通过企业库的配置工具可以很方便的配置企业库信息，但是如果要在web.config中修改其他信息就麻烦了，而且企业库的各模块信息也都在一起不利于日后的维护，所以我们首先就要把企业库的配置信息给剥离出来，然后再根据各模块分成一个一个独立的.config配置文件，统一放在一个文件夹中，这样项目发布后再修改配置信息时也可以立刻找到需要配置的文件。

分离配置文件的方式主要有3种，这3种方式各有优势也各有劣势，主要还是看实际如何应用：

1、使用企业库提供的Configuration Setting（只需配置无需修改代码，分离出的模块无法直接统一查看，只能查看单独模块，推荐）

2、分离出独立config文件或使用编码的形式来读取配置文件（必须编写代码，使用起来较为麻烦，分离出的模块无法直接统一查看只能查看单独模块，不推荐）

3、使用.NET的configSource特性进行配置（无需企业库工具配置，只需分离代码，分离出的模块可以统一查看，但是修改配置文件后所有配置信息又会重新回到web.config中，同时无法修改分离出去的单独配置文件，推荐）

 

一、使用企业库中默认已经提供了Configuration Setting模块来进行配置：

1、首先将各模块的信息先分离成一个一个单独的config文件（包括这个模块的section以及具体的配置）如下（Data Access模块配置文件）：

<?xml version="1.0"?>
<configuration>
  <configSections>
    <section name="dataConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Data.Configuration.DatabaseSettings, Microsoft.Practices.EnterpriseLibrary.Data, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="true" />
  </configSections>
  <dataConfiguration defaultDatabase="EntLibStudy" />
  <connectionStrings>
    <add name="EntLibStudy" connectionString="server=SQL2005;database=EntLibStudy;Integrated Security=True;"
      providerName="System.Data.SqlClient" />
    <add name="EntLibStudySQLite" connectionString="data source=|DataDirectory|EntLibStudySQLite.db3"
      providerName="System.Data.SQLite" />
  </connectionStrings>
</configuration>

2、在企业库中添加一个Configuration Setting模块，然后选择添加一个Filed-Based Configuration Source，将路径选择为刚才所分离好的config配置文件，同时建立一个重定向设置，设置到相对应的企业库模块：

添加Filed-Based Configuration Source

指向配置文件并建立重定项模块

 

 

这样项目中有几个企业库模块就建立几个相对应的配置文件，而且不需要修改任何代码。

 

二、使用编码形式来进行配置：

这种方式使用的配置文件同第一种方式，在配置文件中需要包含section等模块的配置信息，然后在具体使用企业各模块的时候采用如下代码：

//缓存模块
//建立一个FileConfigurationSource来根据文件名读取配置文件
FileConfigurationSource cacheDataSource = new FileConfigurationSource("Cache.config");
//通过模块工厂来读取文件配置源
CacheManagerFactory cacheManagerFactory = new CacheManagerFactory(cacheDataSource);
//建立具体模块实例
ICacheManager cacheManager = cacheManagerFactory.Create("Cache Manager");
cacheManager.Add("test", "test");

//数据访问模块
FileConfigurationSource dbDataSource = new FileConfigurationSource("Data.config");
DatabaseProviderFactory databaseProviderFactory = new DatabaseProviderFactory(dbDataSource);
Database db = databaseProviderFactory.Create("EntLibStudy");

这种方式我个人认为很不方便，每次使用企业库中的模块时候首先要通过FileConfigurationSource 来获取这个模块具体的配置信息，然后才能创建实例对象，如果一旦配置文件名称发生改变将会出现异常，所以并不推荐使用这种方式来管理配置信息

 

三、使用.NET的configSource特性进行配置：

这种方式的好处是显而易见的，就是不用在企业库中添加Configuration Setting，只需单独建立config文件，然后把所需的配置信息剪切到config文件中即可，但是有几点需要注意：

1、有关企业库模块的section信息必须放在web.config中

2、在单独放置的config文件应该是一个干净的XML文件，不能包含有<configuration>配置节，仅仅需要某个模块的配置即可

3、在web.config中必须保留一句指向config的配置节

虽然这种方式操作最善但是缺点也很突出，就是一旦通过企业库配置工具修改过web.config，企业库的所有配置信息又会在web.config中重新产生，同时无法单独编辑分离出去的单独的config文件

具体配置如下：

web.config：

<cachingConfiguration configSource="Configs/CacheConfig.config"/>

CacheConfig.config:

<?xml version="1.0"?>
<cachingConfiguration defaultCacheManager="Cache Manager">
  <cacheManagers>
    <add name="Cache Manager" type="Microsoft.Practices.EnterpriseLibrary.Caching.CacheManager, Microsoft.Practices.EnterpriseLibrary.Caching, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" expirationPollFrequencyInSeconds="60" maximumElementsInCacheBeforeScavenging="1000" numberToRemoveWhenScavenging="10" backingStoreName="NullBackingStore" />
  </cacheManagers>
  <backingStores>
    <add type="Microsoft.Practices.EnterpriseLibrary.Caching.BackingStoreImplementations.NullBackingStore, Microsoft.Practices.EnterpriseLibrary.Caching, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="NullBackingStore" />
  </backingStores>
</cachingConfiguration>

这样便完成了配置，代码中无需进行任何更改，同时在企业库的配置工具中可以查看具体的配置信息，唯一不好的就是一旦你用企业库的配置工具打开过web.congfig文件后，所有分离到各个配置文件中的配置信息又回重新返回到web.config中，可以说是有利有弊。

 

以上三种就是企业库配置信息的分类处理方式，总的来说推荐使用顺序是：第一种>第三种>第二种。不过具体的方式还是要根据各种使用需求情况进行选择。

 

源代码下载：点我下载

 

注意：

1、MSSQL数据库在DataBase目录下（需要自行附加数据库），SQLite数据库在Web目录的App_Data下，由于考虑到项目的大小，所以每个项目的BIN目录都已经删除，如出现无法生成项目请自行添加相关企业库的DLL。

2、由于微软企业库5.0 学习之路这个系列我是准备以一个小型项目的形式介绍企业库的各模块，所以源代码会根据系列文章的更新而更新，所以源代码不能保证与文章中所贴代码相同。

3、项目开发环境为：VS2010+SQL2005。

4、管理员帐户：admin

              密码：admin

 

微软企业库5.0 学习之路系列文章索引：

第一步、基本入门

第二步、使用VS2010+Data Access模块建立多数据库项目

第三步、为项目加上异常处理（采用自定义扩展方式记录到数据库中） 

第四步、使用缓存提高网站的性能（EntLib Caching)

第五步、介绍EntLib.Validation模块信息、验证器的实现层级及内置的各种验证器的使用方法——上篇

第五步、介绍EntLib.Validation模块信息、验证器的实现层级及内置的各种验证器的使用方法——中篇 

第五步、介绍EntLib.Validation模块信息、验证器的实现层级及内置的各种验证器的使用方法——下篇

第六步、使用Validation模块进行服务器端数据验证

第七步、Cryptographer加密模块简单分析、自定义加密接口及使用—上篇

第七步、Cryptographer加密模块简单分析、自定义加密接口及使用—下篇

第八步、使用Configuration Setting模块等多种方式分类管理企业库配置信息

第九步、使用PolicyInjection模块进行AOP—PART1——基本使用介绍

第九步、使用PolicyInjection模块进行AOP—PART2——自定义Matching Rule

第九步、使用PolicyInjection模块进行AOP—PART3——内置Call Handler介绍

第九步、使用PolicyInjection模块进行AOP—PART4——建立自定义Call Handler实现用户操作日志记录

第十步、使用Unity解耦你的系统—PART1——为什么要使用Unity？

第十步、使用Unity解耦你的系统—PART2——了解Unity的使用方法（1）

第十步、使用Unity解耦你的系统—PART2——了解Unity的使用方法（2）

第十步、使用Unity解耦你的系统—PART2——了解Unity的使用方法（3）

第十步、使用Unity解耦你的系统—PART3——依赖注入

第十步、使用Unity解耦你的系统—PART4——Unity&PIAB

扩展学习：

扩展学习篇、库中的依赖关系注入（重构 Microsoft Enterprise Library）[转]