不选或许有千万种理由，但是选择hibernate只需要一个理由就足够了

我觉得LZ应该修改下标题，针对的是ORM技术，而不是hibernate工具。
现在得hibernate不光可以做orm,也直接支持运行sql语句和存储过程，用hibernate甚至可以不用其ORM部分，也可以获得很多好处。
我就有个项目，只用hibernate管理和运行sql语句，sql语句全部在配置文件里面，我想DBA肯定很喜欢。

那得有一定的限定条件才能讨论，例如novembersky举的例子的前提就是提到了数据库要用Oracle。

如果理解成，某个项目的主结构采用面向数据的设计，这种设计可以是和ORM没什么关系的。ORM的起源和这种设计方式没什么关系。

但是反过来说，不能否定其他设计方式采用ORM的整体技术方案。

各种方案都有其优缺点，没有前提的空对空是没有什么太大的意思。

顶，支持。

hibernate本身就有足够的灵活性，可以根据不同模块的业务特点，某些部分用OO的特点，某些部分直接用sql。

这一点我不太赞成，很多人都希望直接把开源软件拿来解决业务问题，这种想法有点儿偏差。

其中最大的问题是：“开源只是一种分布开发方式。开源并不包含商业运作。”

开源就是一群人在很专业的玩某一领域的技术，这就导致了开源搞出的东西很专，在某一方面可能很好用，但是想把它作为一套完整的解决方案就捉襟见肘了。光靠开源社区就可以搞出一套完整的解决方案，无所不包，拿来就用？现在看来是完全不可能的，自己的问题还需要自己花功夫解决。

开源社区会帮你完成一定程度上的对接集成，但是诸如：“客户想要这个东西很灵活，满足他们的所有需求”这种东西靠开源来实现，太不现实了。你是在为甲方定做一套系统，满足甲方的实际需求，甲方没有遵循一套规范，你怎么可能在社区里找到完美的解决方案呢？

  我并非是想找完美的解决方案,而是想从实际角度出发去看待这个框架.就像我之前学习Hibernate我可以说我学的很用心,到了实际开发的时候.我才发现原生SQL 原来封装对象与HQL不一样,更别说学习到的2级缓存这些东西了.在学习的时候,demo小,考虑的少.实际问题一出,怎么用都无头绪.我只想那些高手,能从实际的角度.将Hierbnate的一些细节功能拓展开来讲.
  还有就是,不是要完美解决方案,那种东西,不可能那么容易找到.我不知道JAVAEYE是否做到了,一个异常如果我去百度.或者GOOGLE,要么就是到处复制.搞的到处解决方案一样,不过很多都是不匹配的.而JAVAEYE的思想不就是为了帮助大家更好学习交流的一个比较好的平台么.那么大可以把关于某块的异常曾今解决过的问题帖子,集中一起,也好.可能javaeye 已经做到了,只是我没注意.我是希望能最块的检索到我想要的信息.如果别人解决,我找帖子也块,没人帮忙一个人去解决问题的事.做太多了.好累.

这时就要锻炼自己的平常心了。

如果能快速找到解决方案自然最好，如果找不到解决方案，也不应该埋怨什么，毕竟源代码都在那里了，只要有精力就可以通过代码挖出原因来。如果再有时间，也可以把发掘出的问题解决方案放在网上，帮助其他遇到同类问题的人快速解决那就更好了。环境是靠大家建立的。所有人都贡献一份力量，就会一起得到帮助，所有人都等着别人贡献，最后就什么也得不到。

没什么新意，老生长谈啦。

达人的思想和见识令我佩服，是应该都往这个方向去努力才是啊！！

你的介绍中对hibernate的优点其实都是缺点，而介绍的缺点确是绝对致命的可以让人完全不会去选择的。

有足够的了解你得能说的出来，茶壶煮饺子只会糟蹋饺子

我不喜欢你这种讨论问题的方式，一味的批评，而不提出任何建设性意见，很容易误导其他人。虽然你的比喻非常生动形象，但是让其他人看了稀里糊涂，完全搞不明白你所批判的是什么东西。

如果hibernate提高开发效率和跨数据库都是缺点的话，至少应该稍微说明一下这些缺点会导致哪些后果，给其他人一些警示，而不是空口白话的说：“你就是缺点，你就是错了。”这样对人对己都没有什么益处。

我非常欢迎出现反对的意见，但希望这些反对意见是建立在事实的基础上，而不是臆断出来的。

期待您对上述内容进行补充，帮助大家了解hibernate的缺点，感激不尽。

调存储过程和偶尔配置SQL查询的时候用用DAO没啥不好吧。

即使一般的存取，我觉得也有必要再加一个类，这层只是简单的调用hibernate。
业务层捆死hibernate个人认为还是不太好。只是几行代码和配置的事。

上个帖子是针对贫血模型。
充血模型可能有所不同，但没在实际项目中用过，说不好影响。
哪位折腾过的讲讲？