代码重复随时会产生麻烦，有些人可能对代码做了修改，但是忘了将修改应用于重复的源代码。产生的混乱可大可小，但是无论程度如何，重复都是麻烦的来源。在本文中，IBM 开发人员 Steve McDuff 建议使用配置驱动的开发来解决这个问题。

配置驱动的开发和模型驱动的开发之间的差异是，前者并不限制于代码的模型，比如类、字段和关系。配置驱动的开发（Configuration-driven development，CCD）包含应用程序中可以配置的所有内容。例如，如果体系结构指出某些业务规则必须一致地应用于整个应用程序，那么可以使用配置文件来配置和应用这些规则。

在本文中，我将介绍配置驱动的开发，并解释它如何解决代码重复和修改问题。

代码重复和修改

假设您正在开发的应用程序由以下组件组成：

1.一个数据库

2.带 Web 服务 API 的中间件服务器

3.带基于 Web 的用户界面的中间件服务器

4.使用中间件 API 的胖客户机

图 1. 一个简单的参数

在 图 1 中可以看到，一个简单的参数（比如字符串的长度）将会影响所有四个组件。它还会影响下面的用户文档和单元测试领域：

用户文档：

• 胖客户机
• 基于 Web 的用户界面
• Web 服务 API

单元测试领域：

• 数据库
• Web 服务 API
• 基于 Web 的用户界面
• 胖客户机

图 2 说明了 图 1 所示的简单参数的总体影响。

图 2. 依赖性过多

真是让人吃惊，像字符串长度这么简单的东西竟然不只在四个位置上重复，而是在十个不同的位置出现。字符串长度参数只是一个例子；许多类型的业务规则对于典型的应用程序都有类似的影响。一些规则是几乎任何应用程序中都有的，比如字符串长度和数字的最小/最大值。其他规则专门用来满足特定应用程序的需要。应用程序是否使用签出/签入机制保持一致性？关于信息的这些规则是否从客户机和服务器获得？所有这些因素合在一起，即使是最简单的代码修改也很容易导致大混乱。

传统的解决方案

信息重复不是一个新问题，而且已经有许多工具和技术用来防止这个问题。在本节中，我将讨论对信息重复最常用的一些解决方案。

开发过程

一些开发团队将冗余信息修改纳入严格的开发过程中，以此解决信息重复问题。这个解决方案很繁琐，因为它需要监督和复查，但它是有效的。

设计良好的代码

设计良好的代码再加上对常量的重用，可以减轻代码重复问题。当应用程序的所有部分都用同一种语言编写时，代码驱动解决方案的效果最好。

模型驱动的工具

模型驱动的开发的概念是以配置的形式读取应用程序模型。模型驱动的最大优点是，它们使与对象及其关系相关的繁琐任务自动化。下面是一些流行的模型驱动开发工具：

• Eclipse Modeling Framework（EMF）：它存储类的布局和字段。它为应用程序生成 Java 类、网络接口，甚至还包括数据库映射。通过生成对象，EMF 使编写常用方法的繁琐部分自动化，比如获得器、设置器、相等、复制、克隆、串行化等等。EMF 使用可以存储许多对象定义的配置文件。在多用户环境中，合并这些文件可能导致一些问题。EMF 只能处理应用程序的对象、它们的关系和方法。对于处理定制的业务规则，它没有提供任何帮助。
• UML2：它通过类关系、字段和逻辑的图表描述和说明应用程序。UML 的优点是它与语言无关。在完成逻辑设计之后，从理论上说，可以用任何语言生成对象。
• Ruby on Rails：它从数据库模式中提取模型的配置。然后生成处理业务逻辑、基于 Web 的用户界面和单元测试所需的构架。生产效率的提高主要是由于数据库模式的修改会在代码中传播。

CDD 是如何工作的

我已经描述了配置驱动开发的基础。为了更好地理解它是如何工作的，我们来考虑一个来自真实世界的示例。在本节中，我将描述我的团队在开发 Rational Portfolio Manager 中采用的配置驱动开发解决方案。

在 XML 文件中存储配置

在配置驱动的开发中，开发人员主要在 XML 文件中进行所有修改。与应用程序相关的所有其他文件都从这些文件中读取它们的配置，要么是在运行时读取配置，要么是在构建时生成选择的组件。在 Rational Portfolio Manager 项目中，我们在配置文件中存储以下组件和信息：

应用程序对象

• 它们的关系
• 它们的文档
• 它们的验证规则
• 它们在签入/签出机制中的行为
• 它们在应用程序安全框架中的限制
• 它们的数据库映射
• 它们在可视布局中的位置

错误代码

• 它们的惟一标识符
• 它们的文档
• 它们在运行时生成的消息
• 它们使用的参数

Web 服务接口定义

• 暴露的方法
• 文档
• 它们使用验证规则时用到的参数
• 它们在应用程序安全框架中的限制

图 3 显示典型的配置驱动构建过程。

图 3. 配置驱动构建过程示例

所需的工具

下面的工具对于配置驱动的开发很重要：

编辑工具

在大多数情况下，简单的文本编辑器对于编辑 XML 文件已经足够了。优秀的 XML 编辑器会在修改文件时检验语法的有效性，并简化 XML 标记的编辑。

读取工具

为了从 XML 文件中获得信息，需要利用某种工具将 XML 文件直接装载到应用程序中。例如，可以使用 Java 库 Betwixt 将 XML 配置的上下文填充到 Java 文件。

用来生成工件的工具

在读取配置文件之后，下一个逻辑步骤是让产品的其他部分利用这些配置信息。这时有几种方法。第一种是将配置文件嵌入软件本身，这样就可以在运行时读取它们。另一个方式是使用工具（比如 Apache Commons 的 Java Velocity 引擎）生成代码和文档。

规则

大多数应用程序开发人员熟悉以下规则，但是与 Java 开发或极限编程中的做法相比，在配置驱动的开发中它们的应用方式有所不同。

1. 保持简单

配置文件必须容易理解和改进。尽管这似乎是理所当然的，但是有经验的 XML 用户常常使用不利于 CDD 方式的高级特性，比如那些使 XML 难以读取和理解的语法。

2. 根据需要进行改进

预定义的 XML 布局不会满足每个开发人员的需要。对这个问题的解决方案是，让 XML 布局能够适应需求。根据领域或软件体系结构的不同，类或字段定义中使用的 XML 属性有很大的差异。请记住，改进应该避免用户破坏 “保持简单” 规则。在上面的示例中，很容易发现许多配置参数在几乎所有其他产品中都没有用。市场上还没有工具能够简化它们的实现。

3. 尽早且经常进行验证

常识指出，在开发过程中越早发现错误，就越容易解决。根据这条原则，尽可能早些对配置进行详尽验证是有意义的。例如，可以使用 XSD 或 DTD 文件验证配置文件的 XML 结构。如果需要应用定制的验证规则，那么要毫不犹豫地实现自己的验证工具。尽管编写这些工具花费的时间并不是花费在最终产品的时间，但是这种投资是值得的。