网站的配置文件，可不只仅只要 Web.config 一种，还有很多其他的，下面就来分析常见的几种。

一、Web.Config 的启示
Web.config 的好处就不用说了，下面说他其中的几个限制。

1、对于Web 使用程序来说，修正web.config 文件，会让Web 使用自动重起。

如果我们某个配置，估量到会时常变更，或者不希望修正后，Web 使用就自动重起。就不应该把他配置在 Web.config 中。

举例：
ASP.net 2.0 中新增的 SiteMap 配置文件，显然你一个站点有哪些文件配置信息会比较频繁变更，而且这里的修正，是不应该让站点重起的。
微软也就没把这个配置放到 Web.config 中。当然没放到一同还有其他考虑，后面会提到。

参看：
AppDomain 重新启动可能是基于以下要素：
1、 各种属性 （例如, memoryLimit 属性）被修正，配置文件 节中设置被修正。
2、 Global.asax 或 Web.config 文件修正。
3、 修正 Web 使用程序的 Bin 目录。
4、 病毒扫描软件触及一些 .config files
http://support.microsoft.com/kb/324772/zh-cn
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q324772

2、Web.config 文件不应该太大
否则微软干么还要设置成，每个目录下都可以放一个 Web.config 文件。
不把这些配置都放到一个文件下呢？？

上面提到的 SiteMap 配置文件独立出来的一个考虑就是 SiteMap 文件可能会很大，
另外，用户需求把 SiteMap 作为一个数据源来处理的需求很强烈，所以才会有 SiteMapDataSource Web 服务器控件。紧密跟 SiteMap 文件捆绑。这种特殊需求导致了不把这个信息放到 web.config 中。

二、用自定义配置节、配置节组、配置处理程序声明方式来配置的读写操作。

这套任务机制，就是 Web.config 内在的读写机制， Web.config 的配置是在这套基础上，添加了监控文件改变等逻辑操作的处理机制。

这套机制配置文件的格式：
所有的配置信息都驻留在配置文件中的 configuration 元素中。
此元素中的配置信息分为两个主区域：配置节处理程序声明区域和配置节设置区域。

新增或者调整一个配置时候，需求做的任务：
1、调整新的配置节、配置节组类，确保满足新的，调整后的架构。
所有的这些配置节类都必须从 ConfigurationElement 、 ConfigurationElementCollection 、ConfigurationSection 其中之一的类所派生。每一个配置节一个类，所以你的一个配置需求，可能最后会演化成多个配置类。
2、修正配置文件：
这里包含两部分：
2.1、调整配置节处理程序声明，确保你新的配置结构声明正确。
2.2、调整具体配置值
上述步骤中，在具体调整配置时候，可能有些步骤不需求调整。

这套机制的局限性：
1、每个配置节点都需求一个配置类对应，这个节点的父类只能是 ConfigurationElement 、 ConfigurationElementCollection 、ConfigurationSection 其中之一。
2、一个业务逻辑的配置需求，可能需求多个配置节点配制类对应。
3、业务逻辑类和业务逻辑设置类，绝大多数情况下必须分离，无法整合到同一个类中。
4、配置文件中必须有配置数据提供者声明。
5、新增或者调整一个配置结构比较复杂，有大量实体类需求实现，但是如果这个配置曾经实现后，修正配置的值，则不具备复杂性。只需求修正一个地方即可。

所以这套配置机制不适合的几个场景如下：
1、如果估量到，配置结构会不断变更，则不适合。每次变更修正的东西太多了。
2、如果是一个小型使用，为了实现这种配置，额外的多了不少类，不划算。

但是如果是大型项目，而且设计定型了后，不会大变的情况下，则比较适合。
也就是业务逻辑，和业务逻辑配置可估量的将来，不会发生大变化，则可接受。

三、 Community Server 中 communityserver.config 配置文件的读取方式。

即，把配置文件当 XML 文件来读些，这时候我们就可以把业务类和配置紧密捆绑在一同了。

下面我们看看具体 Community Server 是如何做的。
communityserver.config 配置文件对应的一个配置类 CSConfiguration 。
CSConfiguration 把 communityserver.config 作为一个 XML 文件加载到 XmlDocument 对象中来，而这个 XmlDocument 对象的实例，又被缓存在内存中。

他的这部分实现代码如下：

public static CSConfiguration GetConfig()
...{
 CSConfiguration config = CSCache.Get(CacheKey) as CSConfiguration;
 if(config == null)
 ...{
  string path = null;
   HttpContext context = HttpContext.Current;
  if(context != null)
   path = context.Server.MapPath("~/communityserver.config");
  else
   path = Path.Combine(AppDomain.CurrentDomain.BaseDirectory,  "communityserver.config");
  XmlDocument doc = new XmlDocument();
  doc.Load(path);
  config = new CSConfiguration(doc);
  CSCache.Max(CacheKey,config,new CacheDependency(path));
  CSCache.ReSetFactor(config.CacheFactor);
 }
 return config;
}
Community Server 中，有一个定时计划任务的处理机制，它是在 Web 使用的进程中，定时起一些线程来做一些任务。

这些定时的线程，在它那里叫做 Job 。
每个 Job 的业务逻辑和 Job 的配置信息，它都封装到 Job 类中了。
他的这部分实现代码如下。

public class Job : IDisposable
...{
  public Job(Type ijob, XmlNode node)
  ...{
   _node = node;