DAO如何快速适应业务变更
最近被项目给搞郁闷了,请教各位:
我所在的项目没有敏捷的开发流程,确有敏捷项目的特征。
开发过程中,需求是不断变化的,在项目开始时并不能确定需求,而是逐步给客户demo,逐步修改完成系统。客户在美国,美国那边team根据demo会随时更改domain,我所在的中国team就得不停使project各部分适应domain的更改后还能work,涉及到业务的更改,我觉得还好。可是dao层的设计,使得每次domain更改后,还要花大量人力去修改,这些修改完全就是为了同步dao和domain,使得dao能在domain更改后还能工作。这完全没有意义的工作占了我们不少时间。这其中的更改包括表结构的更改,存储过程(没有业务逻辑只操作数据),dao的实现。
简单介绍下我们dao的结构:根据domain会在oracle db里建立对应的oracle type,然后用存储过程存取操作这些oracle type,这些oracle type用jpublisher生成java class,然后自己写代码实现domain和这样的class之间的转换,这些class的对象是可以直接传给存储过程当参数的。 由此可见,我们domain更改后,要引起多少更该,虽然我们会使用反射去转换domain和与oracle type对应的class,但这些灵活性完全不够。
我潜水在jdon多时了,肯定不少人会和我一样认为,这样的项目结构绝对是有大问题的,oo的特性完全没有了,本来作为能快速适应业务更改的oo的优点现在变成了缺点。各位给点建议,有什么办法可以改善。
这里有几点我认为不能改变的现状:
1, 数据库绝对只能是oracle这样的rdbms,不可能先进到用对象数据库。(银行系统,墨守成规很重要)
2, 不使用hibernate, 以前系统是用hibernate的,因为速度和性能跟不上,才改用我上面说的dao设计。(我说服不了大家又回到or mapping上来)
难道只有code generation 这条道路了吗?
Any suggestion will be appreciated