下面的文章只是让大家认识一下Hibernate的优势和未来，有没有必要学习要看你的实际需求，不过还是建议你在有时间的情况下研究一下，如果能用到项目当中那更好。如果你的基础还没有牢固，请你三思而行。
Hibernate FAQ 初学者必读！
1、Hibernate是什么？
Hibernate是一个优秀的开发源代码的Java对象持久层轻量级封装框架，它既可以用来在Java应用程序中取代大部分JDBC代码，也可以整合到J2EE系统中作为持久层框架。
2、Hibernate的官方网站是什么？
http://www.hibernate.org/
3、Hibernate是谁开发的？
Gavin King
4、Hibernate的下载地址？
http://sourceforge.net/projects/hibernate/
5、Hibernate的文档在哪里？
http://www.hibernate.org/5.html
6、Hibernate的当前稳定版本是哪个版本
Hibernate2.0.3
7、Hibernate有专门的论坛吗？
官方论坛(英文) http://forum.hibernate.org/
国内论坛(中文) http://forum.hibernate.org.cn/
8、Hibernate有例程吗？
http://www.hibernate.org/30.html
-----------------------------------------------------------
Hibernate入门容易，掌握精通我也不敢自夸。我第一遍看Hibernate文档的时候也觉得很吃力，但不是因为Hibernate难掌握而感到吃力，是因为Hibernate文档处处都是持久层设计的经验和最佳实践。Hibernate文档准确的来说，绝大部分内容都在讲对象的持久层设计，而不是简单的Hibernate使用，使用问题查Java doc就够了。所以学习Hibernate，主要是在学习持久层的设计模式，如果你把Hibernate文档都看完了，还整天只会提那些 Hibernate的配置问题，Hibernate的类调用问题，我觉得这样的人还没有真正的入门，算是白学了。
我对Hibernate 的那些配置也不是特别纯熟，每次写hbm，都要对照文档一点点的检查；类调用参数也不太记得，写代码也要Java doc随时备查。但是我在学习Hibernate的时候即集中所有精力来理解Hibernate的运行原理，集中精力来掌握持久层设计应该把握的原则和技巧，这些才对我是最重用的东西。毫不夸张的说，学习完Hibernate，我对JDBC的编程也提高了一大截，更不要说对于J2EE架构的持久层的框架设计，基本上是了然于胸了，即使将来换了API，不用Hibernate的，改用JDO，Castor什么的，这些经验一样照用。
学习Hibernate主要不是在学习Hibernat怎么配置，用工具怎么生成hbm文件，如果你把重点放在这里，基本上等于白学了Hibernate。Hibernate的精华在于无与伦比的灵巧的对象持久层设计，这些持久层设计经验不会因为你不用Hibernate而丧失掉，我自己学习Hibernate，已经明显感觉到对持久层设计能力已经长了很多经验值了，这些经验甚至不光可以用在Java上，用在.net上也是一样。所以Hibernate配置的学习，我只是简单看看，用的时候知道到那里去查就行了，一堆复杂的生成工具我根本就看都不去看，这样算下来，掌握Hibernate的配置，可以用Hibernate来替代JDBC写程序，不过花上3天时间就足够了。我想3天时间对你来说不算很奢侈的学习代价吧。
为什么我这么强调学习Hibernate的对象持久层设计理念呢？那就看你的理想是想一辈子做一个程序员呢？还是想向更高的方向发展呢？从纯做技术的角度来说，职业发展的最高点是“系统架构师”，Bill Gates不是还叫做微软的首席系统架构师吗？System Architect职位需要的是你的学习和领悟能力，如果你不能把学习Hibernate得到的设计经验运用到其它地方，那么你是失败的，也没有资格做 System Architect。
不管JDO也好，Hibernate也好，TopLink也好，CocoBase也好，还是 Castor，还是什么Torque，OJB，软件的使用和配置方法可以各异，但本质上都是ORM，都是对JDBC的对象持久层封装，所以万变不离其宗，如果你完整的学习和掌握Hibernate花了1个月的时间，那么你再学习OJB的时间不应该超过1个星期，因为你已经把对象持久层设计都了然于胸了，你需要的只是熟悉一下OJB的API和配置罢了，至于怎么运用OJB进行持久层的开发你早就已经熟悉了。
所以当你掌握了两种以上的ORM，你应该能够不拘于使用的ORM软件的限制，设计出适合于你的项目的持久层来，这才是System Architect的水准。用金庸小说来打个比方来说吧，张无忌学太极剑，只记剑意，不记剑招，这才是真正的高手，而低手就只会去学习剑招，而不去领会剑招背后蕴含的剑意，所以一辈子都是低手，永远不能真正学会太极剑。所以周颠看到张三丰第二次演示太极剑，招式完全不同就以为是另一套东西，其实本质上都一样。学习Hibernate也不要舍本逐末的去学各种五花八门的工具，重点掌握它的对象持久层设计理念。
--------------------------------------------------------------
我来谈谈我为什么学习Hibernate，希望对大家能有点启发。
在我做过的很多项目的过程中，我一直有一个悬而未决的问题在困扰我，那就是持久层的开发。持久层的开发一般来说要么用CMP，要么用JDBC＋DAO。 CMP就不用说了，它对我来说是一种失败的实践，而JDBC+DAO也存在很多的困难，我很难做到把关系表记录完整的映射到持久对象的关系上来，这主要体现在多表的关系无法直接映射到对持久对象的映射上来，可能是一个表映射多个持久对象，有可能是多个表映射一个持久对象，更有可能的是表的某些字段映射到一个持久对象，但是另外一些字段映射到别的持久对象上。而且即使这些问题都处理好了，也不能直接按照对象的方式来对持久对象（PO）编程，因为存在1：N关系的持久对象的查询其实就是1+n次对数据库的SQL，我曾经有一次失败的持久层设计，结果是某个关联很多其它持久对象的PO一查询就是5n＋1次 sql，速度慢的不得了，最后不得不整个修改底层设计，最后等于是完全抛弃了对象设计，完全是按照表字段进行操作。
但是这样做非常难受，因为系统的设计是从需求设计，系统设计这样自顶而下的，结果都到了详细设计阶段了，被持久层映射问题限制，不得不自底向上修改设计方案，又回到了按照过程进行编程的老路上来，非常的糟糕。
我对这个问题思考了很久，最后终于意识到这其实是一个很经典的问题：对象和关系的映射问题。实际上自从OOP编程流行以后，就存在这个难题了，所以才有人提出关系数据库进行重新设计，改用对象数据库，但实际上关系数据库并没有被淘汰，于是就只能在上层的应用层找解决方案。这时候我明白了我需要的实际上是一种 ORM产品。
我最早想到的ORM就是JDO，于是我下载了两个JDO产品，准备认真的学习一下，但是研究了一段时间之后，我发现我对JDO非常的失望，原因如下：
1、 JDO没有一个好的开源免费实现，好的产品都是商业产品，并且在国内没有销售和技术支持。这就造成了JDO只有学习之用，不能把它用在实际项目中，否则的话，你把软件卖给客户的时候，还要告诉他，你还要另外去买一个国外的软件产品，并且在国内没有技术支持，出了持久层的问题，我们也解决不了，请你自己打国际长途去解决问题，你认为客户能答应吗？
2、JDO不是一个轻量级封装，它试图建立一个完整的持久层框架，但是还很不完善，造成了JDO 感觉比较笨重，很多操作方式令人觉得烦琐和古怪。这加重了程序员学习和编程的负担，而且封装的太多会造成一个严重的问题就是一旦出现报错信息，调试起来非常困难，你很难准确的定位错误究竟出在哪里，封装的越轻，问题越容易定位，越容易解决，封装的越重，问题越复杂，越找不到原因，CMP就是一个很好的例子，出了错误，调试起来非常困难和麻烦。
3、JDO的标准很不完善，存在重大缺陷。最主要的问题体现在PO不能脱离PM（相当于 Hibernate的Session）而存在，这是个非常严重的问题，会造成编程的时候进行大量VO的拷贝操作，烦琐极了；另外一个重大缺陷是静态的 POJO的Enhancer，不能运行期动态Enhance，无法进行增量编译和调试，编程和调试起来非常烦琐，每次都要手共运行一个工具对POJO进行 Enhance；此外还有一些缺陷，例如JDOQL不完善，映射关系的表达不够强大等等。
4、JDO产品的分裂。这个问题也比较严重，由于JDO1.0标准的缺陷，而JDO2.0标准还遥遥无期，而各个JDO厂商为了能够在竞争中脱颖而出，那么除了在易操作性和性能上的提高之外，想要吸引客户，就必须有自己的产品特色。那么1.0标准的缺陷正好给了他们发挥的舞台，每个厂商都会有自己独到的解决方案来解决标准的缺陷，然而这却造成了JDO 产品事实上的分裂。这种分裂严重到什么程度？我可以简单举个例子：你写好的POJO，用一种JDO的Enhancer进行Enhance过以后得到的 PO，在另一个JDO产品上跑不起来。这很像当年Unix的分裂，结果就是二进制代码级的不兼容，而只能在C源代码级兼容。现在的JDO也有这样的趋势，就像App Server的差别一样，一个在Weblogic上开发好的EJB，移植到Websphere，你一定需要重新进行配置。
我心目中的ORM最好有如下的特点：
1、开源和免费的License，我可以在需要的时候研究源代码，改写源代码，进行功能的定制。
2、轻量级封装，避免引入过多复杂的问题，调试容易，也减轻程序员的负担。
3、具有可扩展性，API开放，当本身功能不够用的时候，可以自己遍码进行扩展。
4、开发者活跃，产品有稳定的发展保障。
抛弃了JDO以后，我根据上面的原则，先后排除了TopLink，CocoBase，Castor等，最后选择了Apache OJB和Hibernate。
OJB的排除很容易做出，一是因为它的文档太简单，太少；二是因为OJB计划下一个版本全面支持JDO，它的API会有重大变动，所以现阶段学习OJB是个错误，等它的API稳定了以后再学习不迟。
Hibernate的发现是很偶然的事情，只是在别人提到JDO的产品中，附带提了提而已，但当我开始研究Hibernate之后，我发现终于找到了我梦寐以求的ORM了。
Hibernate 完全符合我上面提到的标准之外，也解决掉了JDO的所有缺陷，而且方式之优雅令人赞叹。Hibernate的文档也是非常非常有特色的地方，它不仅仅是 Hibernate的功能介绍那么简单，它实际上是一个持久层设计的最佳实践的经验总结，文档里面的例子，文档里面的总结全部都是最佳设计的结晶。我认真的把Hibernate读下来的感觉就是，不单单把Hibernate掌握住了，而且对持久层的设计的经验都长了一大块，以前可从来没有觉得持久层的设计还有那么多的学问，也由此感觉到Gavin绝对是一个大牛人。
当然选择Hibernate最最重用的原因是Hibernate是一个我能够完完全全驾驭的了的软件。Hibernate的源代码非常少，而且写的非常简洁，我总觉得挺奇怪的，这么少的源代码能够实现这么多的功能，是个奇迹。 Hibernate的源代码树分的很清楚简单，源代码很易读，我一旦碰到文档中没有讲到的问题，或者文档中提到但是我搞不清楚的地方，我就去源代码中找，所有的问题都豁然开朗，而且让我对Hibernate的运行原理和细节搞的特别清楚，好像Hibernate就像自己写的代码一样，很清楚的知道，怎么写程序可以让Hibernate运行效率最高，最省内存，程序出了错误，很清楚的知道是什么地方的问题，怎么解决。所以用Hibernate让我特别放心，我能够驾驭它，而不像那些过于复杂的软件，本身框架就复杂的很，再加上不开源，出了问题也不知道怎么回事。
------------------------------------------------------------
一、Hibernate是JDBC 的轻量级的对象封装，它是一个独立的对象持久层框架，和App Server，和EJB没有什么必然的联系。Hibernate可以用在任何JDBC可以使用的场合，例如Java应用程序的数据库访问代码，DAO接口的实现类，甚至可以是BMP里面的访问数据库的代码。从这个意义上来说，Hibernate和EB不是一个范畴的东西，也不存在非此即彼的关系。
二、Hibernate是一个和JDBC密切关联的框架，所以Hibernate的兼容性和JDBC驱动，和数据库都有一定的关系，但是和使用它的Java程序，和App Server没有任何关系，也不存在兼容性问题。
三、 Hibernate不能用来直接和Entity Bean做对比，只有放在整个J2EE项目的框架中才能比较。并且即使是放在软件整体框架中来看，Hibernate也是做为JDBC的替代者出现的，而不是Entity Bean的替代者出现的，让我再列一次我已经列n次的框架结构：
传统的架构：
1) Session Bean <-> Entity Bean <-> DB
为了解决性能障碍的替代架构：
2) Session Bean <-> DAO <-> JDBC <-> DB
使用Hibernate来提高上面架构的开发效率的架构：
3) Session Bean <-> DAO <-> Hibernate <-> DB
就上面3个架构来分析：
1、内存消耗：采用JDBC的架构2无疑是最省内存的，Hibernate的架构3次之，EB的架构1最差。
2、运行效率：如果JDBC的代码写的非常优化，那么JDBC架构运行效率最高，但是实际项目中，这一点几乎做不到，这需要程序员非常精通JDBC，运用 Batch语句，调整PreapredStatement的Batch Size和Fetch Size等参数，以及在必要的情况下采用结果集cache等等。而一般情况下程序员是做不到这一点的。因此Hibernate架构表现出最快的运行效率。 EB的架构效率会差的很远。
3、开发效率：在有JBuilder的支持下以及简单的项目，EB架构开发效率最高，JDBC次之，Hibernate最差。但是在大的项目，特别是持久层关系映射很复杂的情况下，Hibernate效率高的惊人，JDBC次之，而EB架构很可能会失败。
4、分布式，安全检查，集群，负载均衡的支持
由于有SB做为Facade，3个架构没有区别。
本文地址：http://com.8s8s.com/it/it10064.htm