muyu – 第 153 页 – 木鱼琐语

robbin：
Hibernate是JDBC的轻量级封装，凡是用JDBC就会封装数据库操作，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个架构没有区别。
四、EB和Hibernate学习难度在哪里？
EB的难度在哪里？不在复杂的XML配置文件上，而在于EB运用稍微不慎，就有严重的性能障碍。所以难在你需要学习很多EJB设计模式来避开性能问题，需要学习App Server和EB的配置来优化EB的运行效率。做EB的开发工作，程序员的大部分精力都被放到了EB的性能问题上了，反而没有更多的精力关注本身就主要投入精力去考虑的对象持久层的设计上来。
Hibernate难在哪里？不在Hibernate本身的复杂，实际上Hibernate非常的简单，难在Hibernate太灵活了。
当你用EB来实现持久层的时候，你会发现EB实在是太笨拙了，笨拙到你根本没有什么可以选择的余地，所以你根本就不用花费精力去设计方案，去平衡方案的好坏，去费脑筋考虑选择哪个方案，因为只有唯一的方案摆在你面前，你只能这么做，没得选择。
Hibernate相反，它太灵活了，相同的问题，你至少可以设计出十几种方案来解决，所以特别的犯难，究竟用这个，还是用那个呢？这些方案之间到底有什么区别呢？他们的运行原理有什么不同？运行效率哪个比较好？光是主键生成，就有七八种方案供你选择，你为难不为难？集合属性可以用Set，可以用List，还可以用Bag，到底哪个效率高，你为难不为难？查询可以用iterator，可以用list，哪个好，有什么区别？你为难不为难？复合主键你可以直接在hbm里面配置，也可以自定义CustomerType，哪种比较好些？你为难不为难？对于一个表，你可以选择单一映射一个对象，也可以映射成父子对象，还可以映射成两个1:1的对象，在什么情况下用哪种方案比较好，你为难不为难？
这个列表可以一直开列下去，直到你不想再看下去为止。当你面前摆着无数的眼花缭乱的方案的时候，你会觉得幸福呢？还是悲哀呢？如果你是一个负责的程序员，那么你一定会仔细研究每种方案的区别，每种方案的效率，每种方案的适用场合，你会觉得你已经陷入进去拔不出来了。如果是用EB，你第一秒种就已经做出了决定，根本没得选择，比如说集合属性，你只能用Collection，如果是Hibernate，你会在Bag，List和Set之间来回犹豫不决，甚至搞不清楚的话，程序都没有办法写。
为什么我这么强调学习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也不要舍本逐末的去学各种五花八门的工具，重点掌握它的对象持久层设计理念。
ORM产品的规范也不是没有，JDO就是一个ORM产品规范，但是遗憾的是JDO太令我失望了，前面一个帖子我详细谈了JDO的缺陷。我第一个关注的ORM就是JDO，如果JDO能够让我满意，我也根本不去学Hibernate了。标准这个东西是双刃剑，在某种程度上，标准桎梏了技术的发展。EJB今天就是一个灾难，EJB够标准了吧，你敢拍胸脯说任意主流App Server上的EJB都可以移植吗？单单你在Weblogic和Websphere上移植就够你受的了。如果你不是经常跳槽，或者你即使经常跳槽，但是你在技术上有足够的影响力，那为什么又不能影响公司来使用Hibernate呢？这难道很困难吗？如果你真的那么在乎标准，你可以使用CMP或者JDO阿，也没有人来强迫你使用Hibernate，你何必一面痛苦的学习Hibernate，一面否定它呢？反过来说，Hibernate既然不是标准，为什么那么受欢迎呢？这反衬了标准的失败。一个标准能不能成功有一定的历史原因，JDBC的成功就是如此，有一个好的历史机遇，但是在ORM领域标准是失败的，你就是强求也没有用。
提到学习方法，想多说两句：
Java本身是一种设计的非常简单，非常精巧的语言，所以Java背后的原理也很简单，归结起来就是两点：
1、JVM的内存管理
理解了这一点，所有和对象相关的问题统统都能解决
2、JVM Class Loader
理解了这一点，所有和Java相关的配置问题，包括各种App Server的配置，应用的发布问题统统都能解决
就像张无忌学太极剑，本质就是一圈一圈的画圆，你要是懂得了太极剑的本质，那么太极剑就那么一招而已，本身是很容易学的，只是难度在于你要能够举一反三，化一式剑意为无穷无尽的剑招，这就需要一点悟性和不断的实践了；反过来说，如果学剑不学本质，光学剑招，你就是学会了1万招，碰到了第1万零1招，还是不会招架，败下阵来。
技术世界本来就是丰富多彩，企图统一标准，实际上也做不到，但是世界本质其实并不复杂。学习技术，特别是某种具体的软件工具的时候，应该学会迅速把握事物的本质，不要过多搅缠细节。软件工具应该为我所用，而不是我被工具所驾驭。当你具备了对整个J2EE架构的设计和实施的能力，你还会被具体的工具束缚吗？哪种工具适合你的架构，你就用什么，哪种不适合你，你就抛弃它，软件皆臣服于你的脚下，而不是你被什么软件牵着鼻子走，到了这种程度，你难道还害怕学习什么新的软件？
我自己也在一直朝着这个方向努力，在我心中，设计软件，架构是第一位的，采用什么技术要为架构服务。如果我发现什么技术对我的架构来说很重要，那么我会花时间去学习，去钻研，就像我花时间去钻研ORM一样，如果我觉得什么技术对我的架构来说没有用，即使技术再火爆，我也不去碰它。
总之要学会抓住本质，驾驭技术，而不是被技术所驾驭。当你掌握了本质原理，其实学什么都很快，毕竟都是相通的，我先看JDO，后看Hibernate，其实两者就很类似，所以学得很快，以后如果有工作需要，要我学习别的ORM，那我也不会觉得有什么困难的，一样手到拿来。
更有说服力的是Unix类的操作系统，那就更相似了，只要抓住了Unix最本质的几点，例如shell命令和编程，文件系统结构和配置，系统启动原理和过程，所有的Unix都是无师自通的。我自己会用Linux，FreeBSD，SCO Unix， Solaris，HP-UX 和 AIX等6种Unix，更体会到一通百通的道理。
拿刚出了光明顶密道的张无忌来说吧，(我很喜欢张无忌这个角色)，他也没有练过什么武功，但是他已经把天下武学之本质：九阳神功 + 乾坤大挪移学会了，所以不管什么功夫，他都是看一遍就会，马上为我所用，看了空性用了一遍龙爪手，就会用龙爪手来破对方；和昆仑派打了一架，就会用昆仑剑法和灭绝师太过招；七伤拳更是无师自通；太极拳也是看一遍就会。
总之，学习方法还是很重要，别被五花八门的技术给搞不清学习方向了。
banq：
Hibernate是好东西，当然也有缺点，Jdon论坛是开放论坛，技术观点百家争鸣是最好的了（技术以外少谈）。
hibernate的缺点我感觉是因人而异的，下面谈谈我个人想法。
虽然XML相当强大，但是我认为它也有一定的适用范围，尤其复杂XML的编制，已经如同编制程序代码，编制程序代码我现在如果没有Jbuilder的语法提示，我早就变成了痴呆，因为我感觉脑子精力是放在refactoring以及代码重用性提取上，所以我做程序，经常重整，最后会形成一个小框架，这些我认为是我的财富，我认为我的重点应该放在这上面，否则，项目做了很多，感觉什么都没得到。
所以，我喜欢图形化编辑工具，我喜欢自动提示的编程环境，但是现在编制复杂的XML，我感觉又一次落入无人访问的荒漠，当然XML编程环境正在成熟，但是如何根据schema来实行自动提示，我想还有一段时间。
简单地用用Hibernate感觉很简单，但是要实现复杂的使用，如一对多或多对多关系，需要编制我认为复杂的xml语句，我有恐惧感，我的经验告诉出错可能性很高，需要Schema手册时刻在心中。
这是一点，Hibernate复杂功能过于依赖XML，虽然JAVA代码减少编制了，但是XML代码编制工作量复杂了。
第二点，Hibernate的HQL是很强大，但是复杂功能过于依赖HQL，HQL是什么，是字符串，是metaData，过去我们是从汇编走过来，难道我们还要复兴它，我用了2年的Perl或Php这样脚本，放弃它就是它是过于字符串，一个字符的大小写错误和空格影响整个系统的重要功能，我不想让系统充满这种风险。
Hibernate是一个好的ORM产品，但是JDO 2.0正在加紧制定，相信所有的ORM产品最终给人是一种完全面向对象语言级别的，可伸缩的强大工具，可伸缩很重要，对于简单应用它也能方便使用，对于复杂应用它同样方便使用。
robbin:
不同意你的观点！！！
1、Hibernate的hbm配置真的很复杂吗？
我不觉得，我还从来不用工具来生成hbm，都是手工来写，一边写一边查看Hibernate的手册就够了，很简单阿，你怎么会觉得难？说到写Java代码，我用的是UltraEdit，一个字母一个字母的敲，Java的类都是见名知意的，而且命名非常规范，记住并不困难。看来你已经被工具宠坏了。
2、Hibernate的强大并不是因为HQL
Hibernate强大在它灵活多变的以各种对象方式来映射数据库，我上面反复的提，这才是它的精华。说实话，我用Hibernate，我根本写不出像Hibernate文档里面那么复杂的HQL出来，因为实在是用不上。HQL的强大只是给你提供了一种解决问题的方法，不是强迫你非用不可，难道HQL强大反到成了Hibernate的缺点？如果要实现Hibernate很复杂的功能，根本就不依赖HQL，而是依赖你用Hibernate精巧的设计对象持久层，这一点，看看Hibernate网站上面的Design Pattern会有很启发。
3、完全面向对象谈何容易？
Java语言自己都不是完全面向对象，有什么道理要求Hibernate也是完全面向对象？
4、可伸缩性
我恰好很欣赏Hibernate的这一点。不论简单应用还是复杂应用一样不在话下。另外Hibernate可扩展性也特别好，如果你需要的功能Hibernate不具备，你甚至可以自己写接口实现类来扩展Hibernate的功能。
来源：【J道】http://www.jdon.com/jive/thread.jsp?forum=16&thread=9441

作者： muyu

OK去了

业务评审

搬回一台电脑

项目组人员频繁变动

《康熙大帝》

《蝴蝶效应》

游青城山

科聚

关于Hibernate的讨论

2003年度JavaWorld编辑选择奖