数据库中的业务逻辑

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

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

顺便问大家个小问题:
是 


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;
}

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

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

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

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

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的缓冲效率是个问题。如果没有自己的业务缓冲层可以参考我上面的例子。

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

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

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

to banq
中国测试工程师非常热门
我不是很清楚其他软件公司的测试是怎么做的，我们公司(外包公司)测试方法，是写程序的人交叉写测试式样书，测试式样书上有各种的测试点，一般以上是代码规约方面的，剩下的就测试结果和预期的是否一样，主要的工作就是截图，成果物基本上就是这些截图，对于代码中的业务逻辑，只要结果正确，是没有人追究的！
Ps：我们的工资不高，在大连仅仅能生存而已

To headmaster:

不清楚你所说的测试是类还是模块级别的。如果是类那么这种方式还可以接受，如果是模块级别的那就有问题了。

“测试用例是设计的一部分”，绝对不是到实现的级别才进行考虑的问题。也不是什么人都可以写测试用例的，如果对于系统间的关系和组合结构了解的不是非常清楚，那么做出来的用例本身就有可能是错误的。

测试工程师应该是一个高级的职位，很显然如果测试人员的水平不能够高于开发人员那么很多系统中真正潜藏的问题怎么可能被发现呢。

现在的很多公司都把测试人员当做纯粹的用户这不叫测试，真正的问题是不太可能依靠最终用户级别的操作发现的。原因有很多，比如并发死锁的bug被击中发生的概率实在是太小了，另外有些时候根本不允许我们在100%实际场景下运行系统，这些时候我们怎么才能发现问题呢？

测试人员应该是站在开发者和实际使用者之间的角色。他们需要是使用者，能够从最终用户的角度考察使用感受；同时他们也是高级的技术人员，也需要从系统的级别进行考察，大到系统结构、协议，小到函数设计的合理性等等，如果没有这样的眼光是很难做到有效测试的。

我们公司的业务逻辑就是全部写在sql里,经常是几千行存储过程不加注释,这些面向过程的东西看起来很难懂,其中有很大一部分的逻辑都不是很复杂，但是由于全部用了sql,导致现在面临一个大麻烦,因为客户那边要求从sqlserver换到人大金仓......,当经理宣布这个决定是,我们都笑了,很无奈。因为这个架构就是面对sql语句的架构,java只不过是个DTO......

to IceQi:

非常感谢你回答我这个问题,但是我在很都的源代码中看到的JAVA只是一个可怜的DTO。
Hibernate她只是因为建表方便?或者她可以更换数据库?或者她提供了缓存?
这让我感慨,感慨我最喜欢的JAVA她在他人眼中只是个DTO。
呵呵.

如果客户随便就能更改后端存储方式，只能说明你的项目太小。

List<User> userList=UserDao.getUsers(); for(User user:userList){ if(user.getName.equals(?)&&user.getPasd.equals(?)) return user;}
这么写，难道是list所有的user对象，再循环查找符合条件的对象？
如果是这样，肯定有问题。

永远无法阻挡别人的愚昧，我们只能尽力帮助那些希望获得帮助的人。

声明:我非JDON枪手。
真是应了BANQ在《《数据库已死》》的一篇文章中的一段
"JAVA被SQL强奸了"。
不只我是这种情况，LZ也是。很同情楼主。我们需要在真理和现实中挣扎。确实挺痛苦。这种情况在JDON里已经屡见不鲜了.

就像IceQi同志说的 =》
永远无法阻挡别人的愚昧，我们只能尽力帮助那些希望获得帮助的人
我觉得对于LZ和我的遭遇，。应该改为：
目前。我们无法阻挡别人的愚昧，我们只能尽力帮助我们自己。

永远不要嘲笑别人愚昧，也许你也正被嘲笑着。

我没有嘲笑别人。

愚昧总是一个过程，而且是相对的，总有人比我理解的更加深刻，所以我也总是会比某些人愚昧。

下页