首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 软件管理 > 软件架构设计 >

数据校验器架构方式组(转)

2012-10-13 
数据校验器架构模式组(转)数据校验器架构模式组级别: 初级刘 岳林 (yuelin_liu@msn.com), 软件工程师2007

数据校验器架构模式组(转)
数据校验器架构模式组数据校验器架构方式组(转)
数据校验器架构方式组(转)数据校验器架构方式组(转)

级别: 初级

刘 岳林 (yuelin_liu@msn.com), 软件工程师

2007 年 1 月 15 日

本文阐述软件架构与设计模式,它为架构师和开发人员提供了一组关于数据校验的架构模式(隔离校验器,可组装校验器,动态策略校验器,动态注册校验器等),数据校验是任何类型的开发中都不可或缺的环节,如果没有统一的架构,可能校验代码会遍布整个应用,如何将数据校验与应用逻辑解耦,如何适应各种粒度的数据和各种复杂程度业务规则,正是本文要探讨的。

在我们各种类型的应用开发中有一个必不可少的环节-数据校验,无论是大型企业应用,还是一个简单的程序。如果没有统一的架构,可能校验代码会遍布整个应用,一旦校验规则改变就需要修改多处代码,这是一种不好的设计,因为数据校验与应用逻辑耦合得太紧。数据校验不外乎语法校验和语义校验两类,本文描述了一组架构上的模式来对这两类需求提供解决方案。该模式组按照待校验数据的粒度大小和业务规则的复杂程度分成多种类型:隔离校验器,可组装校验器,动态策略校验器,动态注册校验器等。大家可以针对自己的应用选择合适的架构。应用这组模式还可以获得一个好处,如果需要的话,我们可以把数据校验器当作一个横切关注点(Crosscutconcern),应用 AOP(Aspect of Programming)技术,这样可以彻底分离出数据校验逻辑代码。


数据校验器架构方式组(转)
数据校验器架构方式组(转)
回页首


数据校验器架构方式组(转)
数据校验器架构方式组(转)
回页首



数据校验器架构方式组(转)
数据校验器架构方式组(转)
数据校验器架构方式组(转)
回页首

|-------10--------20--------30--------40--------50--------60--------70--------80--------9||-------- XML error: The previous line is longer than the max of 90 characters ---------|+ " doesn't match account rule");//validate site codeString siteCode = val.substring(sepNum[0] + sepNum[1], sepNum[0]+ sepNum[1] + sepNum[2]);if (!strat.validateSiteCode(siteCode))throw new DataValidationException("Site code " + siteCode+ " doesn't match account rule");//validate user codeString userCode = val.substring(val.length() - sepNum[3]);if (!strat.validateUserCode(userCode))throw new DataValidationException("User code " + userCode+ " doesn't match account rule");} elsethrow new DataValidationException("The length of input account NO "|-------10--------20--------30--------40--------50--------60--------70--------80--------9||-------- XML error: The previous line is longer than the max of 90 characters ---------|+ val.length() + " doesn't match account rule.");}}

在这里我们再一次用到了 Registry 模式,可以看到这个校验规则类具有管理和缓存策略类的职责。当然我们还可以在该类中增加一个方法regiesterStrategy()用来在运行时动态地增加业务规则策略,但目前我们的应用没有这么复杂的需求,就算将来有也很容易重构目前的架构,所以这个设计活动应该点到为止。这也是设计中的一个权衡点,设计是没有绝对完美的,人们在追逐绝对完美设计的过程中经常把对未来的种种揣测当作真正的需求,结果只能是危及整个设计,导致代码臃肿,难以维护,僵化,灵活性差。适度的设计才是完美的。

动态策略校验器的架构图如下:


图 2:可组装校验器的架构图
数据校验器架构方式组(转)

在本例中,我们并不是从整合遗留资产的角度出发的,在实际的例子中,银行A和银行B可能都已存在各自的校验类,这些类的接口不会是一致的,而且返回类型可能是boolean也可能是异常,甚至银行A是Java应用而银行B是C应用,这样的话我们必须将这些遗留应用中已有的校验类适配成现在的接口,这里可以对具体的Strategy实现类应用Adapter模式。


数据校验器架构方式组(转)
数据校验器架构方式组(转)
数据校验器架构方式组(转)
回页首


数据校验器架构方式组(转)
数据校验器架构方式组(转)
回页首


数据校验器架构方式组(转)
数据校验器架构方式组(转)
回页首


数据校验器架构方式组(转)
数据校验器架构方式组(转)
回页首


数据校验器架构方式组(转)
数据校验器架构方式组(转)
回页首

名字大小下载方法DataValidator.jar39 KHTTP数据校验器架构方式组(转)数据校验器架构方式组(转)关于下载方法的信息数据校验器架构方式组(转)

数据校验器架构方式组(转)

刘岳林,IBM 中国软件实验室成员,在 OOAD, RUP, XP, Architecture/Design Pattern方面有着丰富的项目实践经验,对架构设计,项目、过程管理有过深入的研究,技术方向为 J2EE, SOA, Grid, AOP,PKI。你可以通过 yuelin_liu@msn.com 联系他。

热点排行