from: baijiahao.baidu.com/s?id=159391…
先说hibernate厉害在哪，然后再来说为啥享受hibernate这些便利会有问题。
hibernate让你可以不写sql，这不单可以让你的应用更好移植到其他数据库，更主要是让程序员可以更专注与业务逻辑，更关注于数据和数据、对象和对象之间的关系。hibernate对一对多，多对多关系实现的是非常好的。很关键的一点，它支持lazy，可以让你的数据只在需要的时候被load，听起来非常美是不是？hibernate还有一个很牛的feature就是可以用HQL，这是完全可以把查询映射到你OO模型的查询语言，和ibatis等的映射比起来，还是要方便和感觉强大一些的。
如果这么看，似乎没有不用hibernate的道理，但其实不是的，强烈建议不用hibernate，尤其是需要处理大量数据或者大并发情况的网站服务，那么现在开始说hibernate的问题。
首先，hibernate把数据库和你隔离了，你不需要关注数据库是mysql还是oracle，hibernate来帮你生成查询的sql。但问题也来了，如果你就要用某种数据库特有的功能，或者你就要让查询的sql完全符合你的心意，这就难了。如果使用hibernate，虽然它也能对生成的查询进行一定程度的定制，但就有点隔靴搔痒了，而且你开发起来付出的代价可能更大。至于hibernate对native sql的支持，就像评论中有朋友提到的，其实也还是完善的，有兴趣的朋友可以看看。而且这种native sql还能返回non-managed entity，不走hibernate的cache，优化是能搞了，但如果你整个项目都这么搞，那还是ibatis对sql管理的好些。
第二，很多web服务，对cache的依赖是非常大的，hibernate自带的cache按理说也是很强大的，但是还是不能满足很多需求。
第三，hibernate的确是在你项目开始的时候给你节约了很多时间。但是它让你的业务逻辑模型和数据库模型互相依赖的程度太高了。这短期没有问题，但随着项目的变迁，这些都会改变，在维持这种紧紧耦合的关系的时候，你会发现你的代码特别脆弱，随便改一处数据库的schema，整个java项目可能要改几十处。而且现在mybatis的自动mapping做的也不差，开发起来也没多花多少时间。等项目进入中后期，你需要大量定制和优化查询的时候，mybatis的开发效率就胜出了。
还有一点可能是我个人喜好了，作为一个后端程序员，我比较喜欢每一行代码我都精确知道它到底在干什么。尤其是数据库访问的代码，往往系统的瓶颈就在这些地方产生，每一行都不能小看。我看过hibernate早期版本的部分代码，比我想象的复杂和强大很多。的确很多地方Hibernate可以强大的只用一行代码解决很多问题，但比如说一个update()或者save()到底做了什么，这里既有hibernate本身的逻辑，也有你应用的逻辑，如果这一行产生了问题，你该如何去做？我个人觉得这是很难搞的，还不如一开始费点事，用ibatis这种。
