关于配置文件,在 PHP 的 Zend Framework 中我做过一些简单的关于性能的测试:http://www.mikespook.com/index.php/archives/36。将 ninnypro 的配置文件从 ini 修改为 xml ,并且声称能提高传说中的性能。
最近被调到另外一个在用 python 的组帮忙,阅读了他们的实现服务器端的 python 代码之,配置文件近二十余个,全是 xml 文件。为了使用着些配置文件,从 XMLFile 继承,实现了二十余个 Config 类。
这看起来似乎没什么问题。
是的,一点问题也没有。
- XML是高度结构化的描述方式。
- XML有大量丰富的包、库支持。
- XML的跨语言能力也是相当优异。你可以轻松的用市面上常见的所有语言轻松的掌控 XML。
这些都决定了 XML 作为配置文件,肯定是比 ini 或者自定义结构的配置文件更加优异的结构。同时,大量的实践也证明 XML 的优异性。例如 j2ee 的实践、SOA的实现、Jabber 的应用都说明 XML: is the lord of the configuration。
但是真得一点问题都没有么?
首先,来看一下 Zend Framework 的 Zend_Config。由于 PHP 自身的数据结构特点,Zend_Config_Xml 和 Zend_Config_Ini 两个类都会加载相应的配置文件,解析后作为数组传递到 Zend_Config 类中。也就是说,最终殊途同归,所有的配置都变成了 PHP 的数组。
然后,再来看一下那个项目中的配置文件。结构化的 XML 被 XMLFile 读取,然后转化为 XMLFile 对象。再统一放入 ConfigManagement 中,经过转换,将部分结构转为 dict 使用。
使用配置文件的原因,我猜测是因为以前,编译语言开发的程序经过编译后,不具有动态改变参数的能力。虽然可以从命令行通过传参来在每次运行时修改配置,但是无论是谁需要通过命令行传递成百上千的参数,都会疯掉。而且,命令行传参,不具有结构化的特征。在一些场景下,需要快速修改部分配置,就变得极为困难。
于是聪明的程序员发明了对人友好的、结构化的配置文件,通过读取配置文件来改变程序内部参数的使用。
这一习惯一直沿用至今。伴随 XML 的问世,配置文件的地位再次上升。更有甚者,在开发中不做编码,只写配置。
看出问题了么?
如果还是没有想法的话,那就再来看看脚本语言:
- 脚本语言具有动态性。
- 脚本语言自身就是结构化的。
- 脚本语言可以增强编译语言的动态能力。
在各个脚本语言应用 XML 作为配置文件的实践中,不论是 PHP 的 array,还是 Python 的 dict,无一例外的将配置文件转换为了脚本语言内部的一种数据结构。在多数情况下,这也是 XML 作为脚本语言配置文件唯一的解决方案。
再来看一个问题:在项目中使用 XML 作为配置文件的时候,是否有使用 DTD 作为 XML 的效验工具?
如果答案是否定的,那么 XML作为脚本语言就没有任何优势。没有应用 DTD 的 XML 就如同 PHP 的 array,Python 的 dict 一样。
那又何必要苦苦的追随 XML,不用脚本语言的数据结构来直接编写配置文件呢?
本来,早就像对这个话题写点什么。星期六(2009-09-19)的时候参加了广州技术沙龙,听了朱童鞋的 nginx 代码剖析后,突然有所顿悟:
成功在于细节,性能在于细节。
我觉得配置文件用 array 写然后放入一个 config.php 里面很好啊,搞不懂为啥要用 xml 或 ini 你?
偶们以前不是讨论过吗?当时还有结论:负载在于细节的微调…
另外,XML并不是多么结构优美的形式,当然了,若有XML阅读器例外…
本来XML是为了做格式转换而诞生的,后来程序员们一看,有现成的库处理,还比较方便,于是就用来配置了,哦,我说的是静态语言的程序员们.
当然了..java社区发展到极端..于是提出一个质疑,配置本身是否编程?当然,不少人的答案是肯定的.这是ror的契约式编程能流行的原因..
另外,同样的问题,java语言也有..本来JAVA不是一门太复杂的语言,java刚开始还是以简单著称的(起码比起C++,有巨大的优势),后来硬是要搞一些变态的东西..
更可怕的是java这几年的发展,除了虚拟机能相当的肯定之外,java语言我觉得可以走下坡了..java语言包括什么aop什么鸟东西,包括大量的X模式,大量的新语法特性,就是为了让静态语言动态化..这显然很BT.