配置驱动的开发(下)
 

2009-11-13 作者:Steve McDuff 来源:IBM

 

好处、成本和限制

在采用一种新方法之前,最好是评估一下它的好处和成本,以及不应该 期望从中获得什么。本节概述这三个方面。

好处

减少重复

这种技术的首要好处显然是减少了信息重复,这会提高产品的可维护性和总体质量。

不依赖于特定厂商

由于只使用基本工具来编辑 XML,就不会将自己限制于任何厂商特有的工具。有许多开放源码工具可以用来读取和编辑 XML 文件。

源代码控制

市场上的一些解决方案将它们的输出存储为专有的 XML 格式,几乎不可能对这些文件进行合并。这些 XML 文件之间的引用也会导致问题。在任何时候只让一个团队成员有权修改配置文件是一种效率很差的方法。在多用户环境中,可以用源代码控制工具(比如 CVS、Subversion 或 Clearcase)处理手工编辑的 XML 文件。

对正确的任务使用正确的工具

市场上的大多数工具致力于解决一些非常常见的需求,但是每个产品都有特殊的需求。找到与所有这些需求匹配的工具很困难,甚至是不可能的。定制的配置文件可以只包含与您的项目相关的信息。

技术独立性

一些工具使用配置文件将应用程序与底层技术隔离开。例如,Hibernate 将数据库和对象之间的关系存储在配置文件中,从而将用户与特定厂商的数据库实现隔离开。尽管这种独立性并不完美,但是技术抽象常常是有好处的,因为它有助于以后改进应用程序。

成本

建立结构

建立结构的初始成本是不能忽略不计的。即使使用正确的工具,问题还是会出现。由于有初始成本,配置驱动的开发主要适合于中型和大型项目。

构建过程的复杂性

当从配置文件生成应用程序的组件时,构建过程会变复杂。通过适当的构建自动化,这个成本可以保持在相当低的水平。

限制和折中

业务规则的复杂性

基本概念很容易映射到配置文件中,但是复杂的业务规则就完全不同了。如果应用程序中的复杂规则常常出现小的变化,那么可以创建只存储这些变化的配置文件。考虑到效率,最好是将复杂的业务规则放在代码本身中,而将重复性的概念放在配置文件中。

基础设施成本

对于小型项目,建立基础设施的成本可能比项目本身的成本还高。另外,小项目不会经常受到信息重复的损害。

示例 XML 代码

清单 1 给出一个示例 XML 文件,它代表一个资源(或用户)结构。下面列出示例 XML 代码中的几个属性:

  • Class:Java 类的名称
  • Extends:父 Java 类的名称
  • Abstract:表示在 Java 术语中这个类是否是抽象的
  • TestReady:表示代码生成器是否应该为这个类生成单元测试
  • Field name:字段的 Java 变量名
  • Field type:字段使用的 Java 类型
  • Field label:用户界面上特定字段使用的标签
  • Field min and max:字符串或数字值的最小和最大长度
  • Field default:在创建对象时,应用于一个字段的默认值
  • Field composite:表示字段是引用还是复合的关系
  • Field valid types:表示抽象对象数组中可以包含的有效类型
  • Field mandatory:表示在创建对象时这个字段是否是强制的
  • Field readable:表示用户是否可以读取这个字段
  • 继承的字段覆盖

清单 1. 代表资源(或用户)结构的示例代码 

  Code highlighting produced by Actipro CodeHighlighter (freeware)
  http://www.CodeHighlighter.com/
  <?xml version="1.0"?>
  <object
      class="sample.Resource"
      abstract="false"
      extends="sample.BaseObject"
      testready="false"
      documentation="A resource represents a user of the system.">
      <rule
          type="create"
          documentation="To create a resource,
          the user must have the administrator
          security rights" />
         
      <rule
          type="update"
          documentation="A resource has the right to modify
          itself. Only administrators have the right to modify
          resources otherwise." />
         
      <rule
          type="delete"
          documentation="Administrators have the right
          to delete a resouce." />
      <field
          name="active"
          label="Active"
          type="java.lang.Boolean"
          default="true" />
         
      <field
          name="calendar"
          label="Calendar"
          type="sample.WorkCalendar"
          composite="false" />
         
      <field
          name="contactGroupAssignments"
          type="sample.ContactGroupAssignment[]"
          composite="true">
          <valid-type
              class="sample.ContactGroupAssignment" />
      </field>
     
      <field
          name="name"
          label="Full Name"
          type="java.lang.String"
          mandatory="true"
          max="35" />
         
      <field
          name="password"
          label="Password"
          type="java.lang.String"
          min="3"
          max="16"
          readable="false" />
      <!-- BaseObject -->
      <inherited
          name="parent"
          mandatory="true">
          <valid-type class="sample.ResourceFolder" />
          <invalid-type class="sample.Project" />
      </inherited>
  </object>

使用这个配置文件,可以生成:

  • 数据库布局
  • Web 服务接口
  • Java 模型类
  • 用户文档
  • 简单的用户界面,其中使用标签和文档提供工具提示和帮助文件
  • 对配置中每个属性和规则进行单元测试的框架

结束语

在理想情况下,可以使用配置驱动的开发构建整个产品。开发过程由两个阶段组成:

1.构建需要的抽象工具。

2.使用配置文件构建应用程序,配置文件指出这些工具如何链接在一起,形成最终的产品。

配置驱动的开发并不是一种全新的思想,但是如何在通常受到限制的现代工作环境中有效地运用它是有挑战性的任务。在本文中,我介绍了一种实现有效且成功的配置驱动开发过程的简单有效的方法。


火龙果软件/UML软件工程组织致力于提高您的软件工程实践能力,我们不断地吸取业界的宝贵经验,向您提供经过数百家企业验证的有效的工程技术实践经验,同时关注最新的理论进展,帮助您“领跑您所在行业的软件世界”。
资源网站: UML软件工程组织