Hibernate FAQ-JSP教程,Java技巧及代码

下面的文章只是让大家认识一下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个架构没有区别。