数据库中的业务逻辑

顺便问大家个小问题:
是

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

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

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

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

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

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

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

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

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

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

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

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

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

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