XML格式的网站配置文件常见读写方案比较(转载)

最新推荐文章于 2022-02-07 10:56:45 发布

weixin_30339969

最新推荐文章于 2022-02-07 10:56:45 发布

阅读量94

点赞数

原文链接：http://www.cnblogs.com/koven/archive/2006/07/31/464016.html

版权

网站的配置文件，可不仅仅只有 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;

_jobType = ijob;

XmlAttribute att = node.Attributes["enabled"];

if(att != null)

this._enabled = bool.Parse(att.Value);

att = node.Attributes["enableShutDown"];

if(att != null)

this._enableShutDown = bool.Parse(att.Value);

.......

}

每个 Job 的构造函数，传入参数中都有一个 XmlNode node 对象，这个对象就是配置文件中，对这个 Job 的各种设置信息。

在构造函数中，我们获得这些设置参数，然后按照这些参数启动不同的 Job。

这么做的好处：
1、我有一种新的 Job 类型需要开发时，并且这个需要新开发的Job类型有好几个新的需要配置的信息。

这时候，我只需要手工把配置文件中加上这几种配置，
然后再 Job 类中，实现这个 Job 的业务逻辑和，配置信息的读取。就完成了。

我们一般只变更了两个文件就是实现了这种业务逻辑需求。
如果我们看看用本文中，用自定义配置节、配置节组、配置处理程序声明方式来配置的读写操作，需要变更多少代码呀。

总结

按需选择自己需要的配置文件以及配置读写的工作机制。

转载于:https://www.cnblogs.com/koven/archive/2006/07/31/464016.html