鉴于反复出现讨论hibernate适用性问题的帖子，这次希望有个定论

也不仅仅是hibernate一个框架的问题了，其实可以上升到O/R Mapping的应用策略问题
几乎每隔几周就会出现类似的讨论，比如 主题: 有没有Hibernate的成功大型项目实现？、Hibernate，憋脚的ORM框架
这说明这个问题还是很有讨论的必要。

过去的几次比较热烈的讨论我基本都看了，焦点主要集中在这几个方面：

1、以数据库为中心建模 VS 以领域模型为中心建模：
   老开发人员大多倾向于前者，因为比较符合过去的开发习惯，另外他们强调数据库的生命周期大于App
   向我这样的只有几年工作经验的往往会倾向于后者，因为这能更充分发挥ORM的威力，更符合OO，免去很多维护DB的繁琐工作。

2、Hibernate VS iBatis/JDBC：
   担心失去对SQL待控制权，导致不能做优化，DBA反对
   Hibernate是在JDBC之上的又一层框架，因此想当然的认为其性能不如iBatis/JDBC（我认为这个结论不成立，因为引入一个ORM层给了我们更多机会去优化性能，比如一二级缓存、lazyload、查询缓存，并且方式更优雅）。参考为什么ORM性能比iBATIS好？
   担心OpenSessionInView模式有性能问题（http://www.javaeye.com/topic/17501）
   Hibernate无法应付复杂查询（我认为这不是问题，HQL和criteria查询能力很强，再不济还可以用SQL啊）

3、对Hibernate等ORM框架能否胜任大型项目的怀疑：
   其实项目大小不是技术选型的主要考虑，关键看项目类型，OLTP还是OLAP、广而浅型的还是窄而深型的、数据量大小等等，这些因素更能影响结果

4、Hibernate学习成本高
   不可否认，相对于spring、struts，Hibernate是一个学习曲线陡峭的框架，但是我觉得综合考虑开发效率和长期收益，还是值得学习和采用的

其实有一个事实被很多人忽略了——Hibernate只是对JDBC的一个封装，因此它可以跟iBatis/JDBC在同一个项目中并存，就好比突击步枪和狙击步枪的关系，两者都有存在的价值和适用场合，不能互相取代。
但是，显然突击步枪是大量装备的通用武器，而狙击步枪是少量装备的特种武器

参考帖子：
OpenSessionInView会不会影响性能？
选择Hibernate还是iBatis?
选择Hibernate还是iBatis?
我为什么选择 iBatis 而不是 Hibernate(对于正在选型的人的建议)
Hibernate，憋脚的ORM框架
对迷茫于Hibernate/JPA的人提一些建议。
为什么ORM性能比iBATIS好？

之前已经有过这么多的讨论，你还要再次求证，希望有个定论。 我觉得这意味着在你心里其实始终还在犹豫和矛盾，你对 hibernate 适用性的问题，也是存在疑问的，只不过，你更愿意找到一些更强悍的理由，说服自己。上面列出的几点，看得出来，你是更倾向或者说更期待一个对 hibernate 持肯定态度的答案的。

我个人觉得 ORM 的中心应该是在 M 上，在关系到对象到映射上，hibernate 和 iBATIS 做得都是一样好，不过 hibernate 更快一点，把映射过程帮我们做好了，与此同时，我觉得他是失去了一些灵活性。lazyload 并不能算是他相对于其他 ORM 工具的优势，相反是对自己灵活性缺失后的补偿。iBATIS通过自定义表字段映射等手段，是不需要 lazyload 的。

iBATIS 多出来的工作量，我觉得在项目中是可以接受的。把 hibernate 项目里花在 SQL 跟踪、优化上的时间，足够用来写 iBATIS 的sqlMap 了，并且不会有那么多的“意料之外”。

至于真正需要缓存的系统里面，我想应该不会有人还寄望于数据层的二级缓存吧。自己稍微多做点功，就可以实现命中率高得多的应用层缓存。所以比较二者的缓存机制，我觉得倒是没有多大意义。

1、hibernate没有什么是“意料之外”的故事，一切都显得理所当然，若有意外，那应该归功于盲从，而非被盲从的对象。

2、使用hibernate，我不用去“SQL 跟踪、优化”，看几眼，感觉一下就够了。优化也轮不到SQL，更多的是你的数据库策略上的非SQL层级的优化(比如索引)。SQL没什么好优化的，少读几个列? 没必要；表连接少一点?(不用看SQL，看Hibernte就可以看出来).

3、使用自写的SQL，那就真需要“SQL跟踪”了，你不知道你哪一个地方写错了，这够没意义，而且够烦。

4、使用Hibernate不需要大牛，只要不盲从，回到基本面，从reference开始。
不了解的，不踏实的，新碰到的，那就做做试验--磨刀不误砍柴功。

先到此为止，算是对楼上部分观点的回复

你对我心理的分析非常准确，但对这个问题的分析就比较的一般

“iBATIS通过自定义表字段映射等手段，是不需要 lazyload 的”
这样需要繁琐配置不说，还是静态的，根本没法跟lazyload按需加载相提并论。

“我想应该不会有人还寄望于数据层的二级缓存吧。自己稍微多做点功，就可以实现命中率高得多的应用层缓存”
首先数据访问层的缓存没你说的那么不中用，还是能很大程度上提高性能的，其次，应用层缓存也没你说的那么简单，否则也不会有jbosscache/memcache

hibernate + jdbcTemplate，基本上国内普通开发人员碰到的项目都能满足了，如要再挑刺，那就再加上存储过程吧，还有什么地方不满意的吗？

我只是提到了 iBATIS 对自定义关系、对象映射的支持，并没有说 iBATIS 不支持动态的 lazyload 啊。 事实上是，iBATIS 和 hibernate 一样，同样提供基于动态代理和 cglib 的动态延迟加载，在这点上，应该是可以“相提并论”的吧。 

不是太复杂的业务模型中，我通常采用静态的自定义映射配置，这个可能每个人的重视程度是不同的，前面 Qieqie 说道他觉得没有必要对查询做列选择，我自己是持不同观点的。 不必要的 blob、clob 字段，我会有意识的去避免加载。 当然，hibernate 和 iBATIS 都是有一些相应的措施去解决这个问题，我的考虑是，这种自定义的静态配置，在 iBATIS 里是一劳永逸的，有 ibator 之类的插件帮助的话，甚至它会帮你做这些静态配置，我为什么不选择这样做呢。

再说数据层的缓存，一个中等复杂程度的系统，命中率应该在 10% 以下吧，hibernate 会比 iBATIS 高一些。 我是不会依赖这一层的缓存的， 自己 extend 一个 LRUHashMap，出来的效果会好得多。 我自己实现了一个支持 LRU、TTL 的 cache 层，代码量很小（因为有 LRUHashMap 的支持），大多数场景够用了，除了分布式的支持。 数据层的缓存，开着就开着，确实也有一点用，不用也白不用 

我有几个预言......

1.orm工具将被oodb取代.....
2.数据库索引和数据将被分开处理
3.分布式数据将成为应用主流...

jdbc,iBATIS,hibernate真的有本质区别么？扳手和活动扳手的区别罢了.....当然，你也可以选择用钳子...

"但是，显然突击步枪是大量装备的通用武器，而狙击步枪是少量装备的特种武器." ---------经典!

那是不是说大多数人都会习惯性的使用"常规武器"呢? (尽管我也想学会用特殊武器)

就一点就够让人讨厌了,hibernate天生就是贫血

hibernate,的查询速度肯定不如数据库的查询速度! 特别java这种语言,计算数据不太快! (多种条件组合的查询不用说了) 数据库查询速度经过了10多年的锤炼了! 在压力的情况下hibernate禁不起!