LegendShop已经放弃了Struts，转投到Spring MVC，但是Hibernate还是保留了。为什么？Hibernate适合做企业级应用，原因且听我们细细道来。
huashuizhuhui 写道
fainfy 写道
peihexian 写道
说hibernate好用的人，你开发的系统业务数据量没上过几百万上千万的话别说话。
几百万上千万就把hibernate用跨了，说明你根本就是在乱用。
我这里数据量没这么大，没有发言权，你说说你是怎么用的啊
说说我们LegendShop的选择吧，我们已经放弃了Struts，转投到Spring MVC，但是Hibernate还是保留了。
原因有：
1. 我们是做平台的，客户要求多种多样，我们是需要支持多个数据库的，Hibernate可以比较容易屏蔽数据库的差异；
2. Hibernate采用面向对象的方式来写SQL，也就是HQL和Criteria,在数据库和Dao之间多了一层，数据库的改动可以通过映射关系屏蔽部分影响。
3. 因为我们是要不断的增加功能，偶然要做做系统重构，快速快发尤其重要，Hibernate的代码量和改动量都要比其他框架来的少，起码经过我们的封装已经使得用起来是很简单了。
4. 对于性能有影响的地方和很难用Hibernate表达的地方我们会采用JdbcTemplate，或者采用View封装一次再map到Hibernate，采用Hibernate也不排斥其他持久层框架的存在。
5. 尽量少用One to many, Many to one等功能，可能这里不太OO，但是代码明了,不容易出问题。
6. 我们暂时还没有遇到几千万的数据量那么大的客户，要做到那么大数据量的时候也可以从数据库，系统，网络各个方面来优化。系统推到重来也不是什么问题。
7.Hibernate的一级缓存对于长Transaction的业务复杂的代码反而有好处，见上面的某些分析。
8. 采用缓存和静态页面可以消除部分性能影响，或者采用数据库特有功能，不过取消Hibernate的二级缓存，采用Spring的缓存或者自己搞缓存。
9. 文档多，容易解决问题，也是JPA标准的重要参考。
Hibernate不好的地方：
1. 多占内存，因为他需要把domain对应的configuration都load到内存里面去，多用内存是正常的，但是出现OutofMemerey肯定不是Hibernate的问题了，一般应用内存还是够的。
2. 性能问题。Hibernate或者Ibatis也好，最终都是通过反射把ResultSet变为对应的Domain Object,跟了一下Hibernate的内部代码，好像是用Method.invoke来调用get 和set方法的，用了Cglib或者动态代理方式，这个方式肯定是要比直接调用get和set方法要慢的。在JDK不断优化的今天，这个差距应该会缩小。 但是Ibatais应该也是通过这个方式来做，没有看过不太肯定。Hibernate多了一个将HQL或者Domain Object转化为SQL的过程，这个过程也会消耗一些性能，例如字符串拼接，记录Domain Object的关系等。
经过以上分析，可能Hibernate会给我带来一定的性能损失，但是我可以通过其他办法来弥补，内存就更不是问题了。但是他确实带来了比较好的地方，因此我们会继续用Hibernate。
所以说Hibernate适合做企业级应用，对于那种内存和性能要求都很高或者本来就用Ibatis的情况，其实可以选择Ibatias或者JdbcTemplate的。就性能而言，
JdbcTemplate > Ibatis < Hibernate
除了缓存的作用外只说DB操作，纯JDBC是最快的，因为那样没有任何负担，但是代码搞得很难看，你会这么选择吗？