《Java组件设计》第四章 配置组件

4         配置组件

在本书的第二章：组件设计中，对组件设计有一个重要的原则，那就是组件自己不能带有任何配置文件。组件应该合理暴露出自己的接口方法，所有的配置行为，都应该通过接口方法的调用来进行，这样就可以满足各种不同环境集成的要求。

依据这个原则，每个应用都可以集成很多不同的组件，而这个应用本身只有一个配置文件，集中配置了这个应用所需要的所有配置信息。应用程序从这个配置文件中读取所有的配置信息，然后将配置参数通过组件的接口方法调用，设置到各个组件中。

因此，我们需要一个读取配置文件的组件，供应用程序来调用，读取这个应用的统一配置文件。这个组件，以配置文件为输入，提供接口方法供应用程序读取各种配置参数。那么，配置文件的格式和结构，就决定了配置组件的设计。

那么，应用的配置文件应该是什么样的呢？

4.1        配置文件格式

我们看看开源社区的框架、别的公司的商业产品、自己公司的项目或产品，会发现配置文件有很多种，有 .properties 、 .ini 、 .txt 、 .config 、 .xml 等等。那么，我们选择那种呢？还是各种格式都支持，全部通吃？或者，每种写一个组件，应用程序想用那种配置文件，自行选择相应的组件？

我们先来分析一下，主流的几种配置文件格式：

1)     .properties 、 .txt 、 .config ：

这三种基本一致，纯文本文件，文件内部无层次结构，每行一个独立的配置项。

优点：简单、易用

缺点：配置复杂的参数，尤其带层次结构的参数无法支持。

2)     .ini ：

ini 文件是在 Windows 上广泛采用的配置文件，具备了前面三种格式的全部优点，并且增加了 SECTION 的支持，把逻辑相关的参数放在一起，非常直观，配置和管理起来也非常方便。

优点：简单、易用、功能较强

缺点：配置复杂的参数，尤其带层次结构的参数无法支持。

3)     .xml ：

xml 文件有严格的语法规则，校验容易，扩展性非常好，在各个领域都得到了广泛的应用。

优点：标准化，有工具和 API 支持，扩展性好，支持复杂结构的配置非常容易。

缺点：复杂、易用性差。

 

这几种配置文件的格式，针对不同的应用场合，都获得了广泛的应用，不存在谁绝对比谁好的问题，主要是看适用那种场合。那么我们的应用，是那种场景呢？

我们立足在电信应用或企业应用，会采用很多的组件，组件的功能会比较复杂，应用本身的功能逻辑也复杂，因此简单的配置不太可能满足后续日益复杂的业务发展需要。因此，纵观以上三种，能满足复杂参数配置的只有一种： xml 。那我们只能选择这种了。

4.2        DTD，还是Schema

作为 XML 文件，通常要确定这个 XML 文件中可以写哪些元素，每个元素有哪些子元素，每个元素可以有哪些属性。这样才构成严格的语法规则，用于校验文档是否是良构的。

一种是用 DTD 来定义，另一种是用 Schema 来定义。

我们，选择哪一种？

我们要写的这个读取配置文件的组件，是个通用的组件，不会随应用的变化而变化。但应用和应用，会差别很大，不同的应用集成不同的组件，不同的组件需要不同的配置项，这些信息，我们的配置文件读取组件都是不可能知道的。

因此，如果我们定义一个 DTD 或者 Schema ，就限制了配置参数的结构。我们定义的 DTD 或者 Schema ，一定是基于我们目前对配置参数的认识和统一抽象，如果将来某个组件的参数不是这样的结构，那么我们将无法配置这个组件。

考虑再三，最后决定不写任何的 DTD 或 Schema ，留给应用自由定义。

可是，如果连 DTD/Schema 都没有，我们怎么解析这个配置文件？

请继续阅读。

本文出自 “expert” 博客，转载请与作者联系！