发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 CQRS 扩展性 并发编程 事件溯源 分布式 SOA
1 2 3 4 下一页 Go 4

数据库中的业务逻辑

              
2008-11-28 16:51
赞助商链接

最近在做一个系统,团队开发的,外包项目,日本那边发过来的,我作为一个小小的程序员对软件的框架结构没有决定权,但是有发表言论的权利,在公司还不敢叫嚣,来这里和大家一起分享,这个项目主要框架使用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修改过]

2008-11-29 14:35

楼主实在是让人同情啊...

顺便问大家个小问题:


User user=UserDao.getUser("select * from user as u where u.nam=? and u.pasd=?");

还是:

List<User> userList=UserDao.getUsers();
for(User user:userList){
if(user.getName.equals(?)&&user.getPasd.equals(?))
return user;
}

这两种查找方法,请大家说说看法.

2008-11-29 18:39

>>一个小小的业务需求改变需要改变的代码是相当多的,比如增加一个表单的元素,需要更改form,action ,service, dao中的sql

>>所有的业务逻辑都包含在这个sql文中(sql行数之庞大,看的我眼花缭乱)然后将SQL再传给oracle,oracle经过查询或者更改操作以后返回数据到页面

害怕,我确定我很害怕,但是能有什么办法?

2008-11-29 19:36

TO:headmaster
有很多事情其实是不如意的,我们有时候只能务实一点。反过来想想看如果我们有了高级的思想,那么低级的任务也能比别人做的更好了。

TO:yinyousong
显然第二种方案更好一点。

对于:
User user=UserDao.getUser("select * from user as u where u.nam=? and u.pasd=?");
DAO绝对不是一个专门执行传入SQL语句的执行器,他是一个数据IO业务过程的封装。反过来说DAO可以解释一些业务参数从而应用于数据的读写,比如这样的接口UserDao.getUser(Object minAge, Object maxAge),在接口的内部将业务数据转换成SQL的参数。

对于:
List<User> userList=UserDao.getUsers();
我觉得这样的DAO使用方式不太恰当,一般情况下直接依赖DAO的缓冲效率是个问题。如果没有自己的业务缓冲层可以参考我上面的例子。

2008-12-01 08:49

>我的工作恰恰是做测试的
所以中国测试工程师非常热门,因为那些老板只知道找擦屁股的人,不知道从当初设计下功夫。他们以为软件象实物雕塑模型,大体功能出来后,那些BUG只是实物雕塑的小修小改,实际不知道,很多难以克服的BUG就是因为设计方向的错误,或者就象DDD说得那样:没有和客观世界的规律共振。

你这个项目就只能靠你们这些测试工程师去弥补,注意工资可不能少要,因为你们最重要,我经常看到很多软件公司最后最重要的位置是那些BUG修复最多的人。不知公司老板怎么想:你是想给他们做经理还是被人卡住喉咙呢?

这些都是因为对于软件不专业,愚昧导致的现状。是怪圈。

4Go 1 2 3 4 下一页

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系管理员 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com