数据库中的业务逻辑
最近在做一个系统,团队开发的,外包项目,日本那边发过来的,我作为一个小小的程序员对软件的框架结构没有决定权,但是有发表言论的权利,在公司还不敢叫嚣,来这里和大家一起分享,这个项目主要框架使用struts,web server是tomcat5.0.30,标签基本上都是公司内部人员根据业务需求更改的,使用效果不佳(调试程序会出现莫名的错误)基本的架构是 form提交后经过struts的Action,action进行数据的验证,通过调用validator中的方法,如果错误,则显示错误信息,程序暂停,如果验证通过,则调用service,这个service就是我所的业务逻辑,service又会去调用dao,dao中的方法主要生成SQL文,然后返回SQL文到service,通过apache的dbutils包的工具类进行数据库操作,将查询的结果返回到action中,action将结果保存在session或request中,然后经过自定义的标签放回到页面上。
对于这个项目我是相当的反感,但是无能为力,因为I AM A LITTLE potato,公司不会因为我的反感更改框架以及设计模式,在这个项目中基本上看不到OO的思想,java的所有作用基本上是sql文的传输工具,将用户的需求翻译成sql以后,所有的业务逻辑都包含在这个sql文中(sql行数之庞大,看的我眼花缭乱)然后将SQL再传给oracle,oracle经过查询或者更改操作以后返回数据到页面,OK,我的头都要大了。对于这种设计我实在是不敢恭维。
为什么有那么多好的设计方式不用而偏偏选择这种方式呢?实在搞不懂,一个小小的业务需求改变需要改变的代码是相当多的,比如增加一个表单的元素,需要更改form,action ,service, dao中的sql,调试起来也是相当的麻烦,而我的工作恰恰是做测试的,数据库中的表都是独立的,一共有150多个表,有很多的数据冗余(数据库是日本人设计的),至于OO中的聚合,包含都没有,每一个form中都会有属性的重复
[该贴被headmaster于2008-11-28 16:53修改过]