代码配置 vs. 配置文件
另一个问题相对独立，但也经常与其他问题牵涉在一起：如何配置服务的组装，通过配置文件还
是直接编码组装？对于大多数需要在多处部署的应用程序来说，一个单独的配置文件会更合适。
配置文件几乎都是XML 文件，XML 也的确很适合这一用途。不过，有些时候直接在程序代码中
实现装配会更简单。譬如一个简单的应用程序，也没有很多部署上的变化，这时用几句代码来配
置就比XML 文件要清晰得多。
与之相对的，有时应用程序的组装非常复杂，涉及大量的条件步骤。一旦编程语言中的配置逻辑
开始变得复杂，你就应该用一种合适的语言来描述配置信息，使程序逻辑变得更清晰。然后，你
可以编写一个构造器（builder）类来完成装配工作。如果使用构造器的情景不止一种，你可以
提供多个构造器类，然后通过一个简单的配置文件在它们之间选择。
我常常发现，人们太急于定义配置文件。编程语言通常会提供简捷而强大的配置管理机制，现代
编程语言也可以将程序编译成小的模块，并将其插入大型系统中。如果编译过程会很费力，脚本
语言也可以在这方面提供帮助。
通常认为，配置文件不应该用编程语言来编写，因为它们需要能够被不懂编程的系统管理人员编
辑。但是，这种情况出现的几率有多大呢？我们真的希望不懂编程的系统管理人员来改变一个复
杂的服务器端应用程序的事务隔离等级吗？只有在非常简单的时候，非编程语言的配置文件才有
最好的效果。如果配置信息开始变得复杂，就应该考虑选择一种合适的编程语言来编写配置文件。
在Java 世界里，我们听到了来自配置文件的不和谐音——每个组件都有它自己的配置文件，而
且格式还各各不同。如果你要使用一打这样的组件，你就得维护一打的配置文件，那会很快让你
烦死。
在这里，我的建议是：始终提供一种标准的配置方式，使程序员能够通过同一个编程接口轻松地
完成配置工作。至于其他的配置文件，仅仅把它们当作一种可选的功能。借助这个编程接口，开
发者可以轻松地管理配置文件。如果你编写了一个组件，则可以由组件的使用者来选择如何管理
配置信息：使用你的编程接口、直接操作配置文件格式，或者定义他们自己的配置文件格式，并
将其与你的编程接口相结合。