选择Hibernate还是iBatis?

H和I应该能并用吧？从同一个连接池获取连接。。。各自用在最擅长的地方！

感觉IBATIS里面可以封装我们优化过的SQL语句...而HIBERNATE无法实现....
做为程序员..当然喜欢HIBERNATE...省事了..
做为项目经理,系统管理员,DBA..会更喜欢IBATIS,因为IBATIS可以使用他们优化过的SQL语句,项目效率,稳定性会大大增加.

iBATIS 官方列举的 Feedback，其中包括 myspace.com 这样的大型站点的使用反馈。可以参考一下：

http://opensource.atlassian.com/confluence/oss/display/IBATIS/Feedback+and+Experiences

选取ibatis，较之直用JDBC，基本不会性能的影响。

这么多人认为使用hibernate存在效率问题？

要解决这个问题，必须首先回答：你的业务逻辑准备放在SQL（包括SP）里面，还是java代码里面？

或者，更本质一些，你怎样看待关系数据库？A.用SQL作为与它交互的媒介，让它为你处理数据，还是 B.把它仅仅当做一个持久层的介质，将数据转换成object graph，在java中处理它们，再写回去？

最简单的例子莫过于上面有人提到的，计算一个订单的总价，你愿意

select sum(price*count) from order_line where order_id=?

还是

for( l:orderLines){
  sum += l.getPrice()*l.getCount();
}
return sum;

这个问题会引起太多的争论，一言难尽。我仅仅描述一个现象：教一个大学有SQL基础的新手，学1个月的Oracle PL/SQL及简单SQL tuning，他基本上就可以开始干活了；掌握同等程度java基础的人，用1个月学习hibernate或其他O/R工具，用java去做，要达到同样的生产率，执行效率及代码质量，几乎是不可能的。

所以，问题往往就变成这样：使用OO语言而带来的好处，是否可以抵消或者超过它所带来额外人力成本？

同意

hibernate的所谓效率损失是用来达到扩大化OO效力的,而不是“Java操作数据库”所必须的

相对独立的两部分如果需要沟通，对整体对来讲势必会有这样或者那样的损耗。这是客观规律。

归结到根本如果所谓的“使用hibernate”单纯以“可以操作数据库”为目的，用jdbc 就可以了,搞个单实例的 connection getter 充其量要自己重写一个池。而且门槛不高,对新手来讲项目可控性好的多.在人力资源（至少是低端人力资源）急剧膨胀的今天，我没感觉到修改一个或多个sql语句是很难实施的工作。ibatis足够了

p.s. ：to seacat

出现这种情况的原因和EJB的问题有点相似。那就是恰恰是数据库能，而不是不能       

怎样才算 do one-thing well 呢

莫非数据库还是太瘦麽？处理过程甚至对象应不应放到数据库里面去？

既然可以处理过程为什么不能处理对象？是无能还是无视呢.我想是后者.