配置驱动的开发(上)
作者:网络转载 发布时间:[ 2012/8/20 15:05:08 ] 推荐标签:
代码重复随时会产生麻烦,有些人可能对代码做了修改,但是忘了将修改应用于重复的源代码。产生的混乱可大可小,但是无论程度如何,重复都是麻烦的来源。在本文中,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. 依赖性过多
真是让人吃惊,像字符串长度这么简单的东西竟然不只在四个位置上重复,而是在十个不同的位置出现。字符串长度参数只是一个例子;许多类型的业务规则对于典型的应用程序都有类似的影响。一些规则是几乎任何应用程序中都有的,比如字符串长度和数字的小/大值。其他规则专门用来满足特定应用程序的需要。应用程序是否使用签出/签入机制保持一致性?关于信息的这些规则是否从客户机和服务器获得?所有这些因素合在一起,即使是简单的代码修改也很容易导致大混乱。
传统的解决方案
信息重复不是一个新问题,而且已经有许多工具和技术用来防止这个问题。在本节中,我将讨论对信息重复常用的一些解决方案。
开发过程
一些开发团队将冗余信息修改纳入严格的开发过程中,以此解决信息重复问题。这个解决方案很繁琐,因为它需要监督和复查,但它是有效的。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11