我为什么选择 iBatis 而不是 Hibernate(对于正在选型的人的建议)

我承认我对Hibernate的理解并不深入，代码也没有仔细的读一读，对你所说的工具，我一样都没有用过。很是惭愧～

很高兴能见到对Hibernate很熟悉的人！我现在有个问题想要请教一下，在我看来要解决 CRUD　的基本操作都是比较简单的。就算是JDBC，我们也写过代码自动生成的工具，可以根据一些META信息(如DDL或PowerDesigner 的PDM)自动生成 Java 对象，并生成相关的 CRUD 代码。但是一般出报表才是比较麻烦的。

如果是以对象的方式来load数据，再进行加工处理，那会load很多不必要的数据，严重影响系统的性能。一般来说我们会根据报表的需要，产生一些中间视图或TEMP表（这些数据可能来自很多不同的系统），只取需要的数据进行分析和处理。不知道你说的这些工具是否能完成这样的任务呢？

另外，你所说的工具似乎比较适合从零开始设计开发的系统，但是往往我们不得不与现有的系统进行集成，有些是我们自己做的，有些是别的公司做的，像 ClearQuest/Documentum/TeamTrack etc.在这种情况下，不知道你说的工具还能很好的支持吗？

谢谢你抽时间来回答我的问题

Hibernate对于遗留系统的支持性做的还是相当不错的，在损失掉一定的对象建模的情况下，可以良好的支持，当然Hibernate付出的代价就是框架需要做的更加复杂。这种对遗留系统的兼容态度(或者说妥协态度)和RoR的ActiveRecord刚好是两个可以参照的对比。

ORM适用的领域是OLTP，而不是OLAP。如果以大量数据分析和数据运算为主的OLAP类型的系统，不要说Hibernate，任何一个ORM都不擅长。讨论这个问题的前提是限定讨论范围。

都是以JDBC为基础的，相信两者的执行性能不会真差到哪里去，两者也不会真有什么东西一定是你能做，我就搞不定的。

至于选择哪一个，影响决断的因素应该在技术之外了。

Robbin，谢谢你回答我的问题。
我同意你的观点。任何技术其实都有一个适用的 scope，不可能是万金油，什么都能很好的解决。针对要实现的系统，选择合适的技术与策略，才比较理性。

我对 ORM 感到别扭的是，它是以 RDBMS 为基础，然后期望在 RDBMS 和 OO 之间建立起桥梁。它有Criteria Query，但是就易用性和实用性来说，肯定是没有　HQL　来得实在。可是写 HQL 又没有 SQL 来得直观，　我不知道Hibernate的专家们是否都不需要调试HQL，不用将 HQL 转成 SQL 在RDBMS里调试一下，我是经常要这样做的，因为我不确定HQL转换出来的 SQL 到底是不是我要的语句，于是我不可避免的要在 RDBMS 和 OO 之间来转换。所以我不太明白，怎么可能抛开 RDBMS ，完全基于 OO 去实现一个系统。

没有必要追求过于纯粹的架构OO，需要用SQL的地方，只管用好了。特别是在使用spring HibernateTemplate的时候，可以混用JDBCTemplate，两者会共用同一数据库连接。

hibernate的解决方案全面 ，并且适合于跨数据库的移植

在hibenrate3中也解决了批量删出的问题。

作为一个orm产品做到这种程度已经是够优秀的了!

更喜欢OO  嘿嘿:)
关于楼主大哥的更新多次查询的"问题"我认为不是"问题":)
因为更新就伴随着更新情况或条件
H也可以不通过查询直接更新吧:)....

谢谢,真心的谢谢
一个学习中的新人真诚的留言

                  ---王炳焱

看完了所有的帖子



谢谢,真心的谢谢
一个学习中的新人真诚的留言

---王炳焱

如果追求OO的话,从OO->数据库设计~会发现HIBERNATE多么的便利~

前面牛人们说了很多了，随便写点自己的感受，ibatis起码有两点致命伤：
无法跨数据库（虽然有些人认为项目开发一般不用换），直接导致缺少物理分页的支持，乐观锁的透明支持等
查询缓存的粒度太大，基于statement而非entity id，基本导致entity cache不可用。

前面都说了，hb和ibatis都是基于JDBC的，本质上不会有啥区别。ibatis这样的纯sql mapping工具根本无法和hb抗衡，无非是jdbc的有益补充而已。

说hb性能有问题基本上只可能是hb的没用好，更何况长远来看hb更符合新的规范已经