XML格式的网站配置文件常见读写方案比较(转载)
网站的配置文件,可不仅仅只有 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 的业务逻辑和,配置信息的读取。就完成了。
我们一般只变更了两个文件就是实现了这种业务逻辑需求。
如果我们看看用本文中,用自定义配置节、配置节组、配置处理程序声明方式来配置的读写操作,需要变更多少代码呀。
总结
按需选择自己需要的配置文件以及配置读写的工作机制。