作者： muyu

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

最佳Java数据存取工具奖
CocoBase Enterprise O/R 4.5, Thought Inc.
Hibernate 1.2.4, hosted by SourceForge.net
Oracle 9iAS TopLink, Oracle
最佳Java IDE
Borland JBuilder 8.0, Borland Software
Eclipse 2.1, Eclipse.org
IntelliJ IDEA 3.0, JetBrains
最佳Java性能监视、测试工具
JProbe 5.0, Quest Software
JUnit 3.8.1, JUnit.org
Optimizeit Suite 5, Borland Software
最佳应用服务器
BEA WebLogic Server 8.1, BEA Systems
IBM WebSphere Application Server 5.0, IBM
JBoss 3.0, JBoss.org
最佳Java设备应用开发工具
IBM WebSphere Studio Device Developer 5.0, IBM
Java 2 Platform, Micro Edition (J2ME) Wireless Toolkit 2.0, Sun Microsystems
Sun ONE Studio 4 Update 1 Mobile Edition, Sun Microsystems
最佳Java-xml工具
JAXB (Java Architecture for XML Binding), Sun Microsystems
Xalan-Java 2.5, The Apache XML Project
Xerces2 Java Parser 2.4, The Apache XML Project
最佳Java安装工具
InstallAnywhere 5, Zero G
InstallShield MultiPlatform 5, InstallShield
Java Web Start 1.2, Sun Microsystems
最佳Java书籍
Java Development with Ant, Erik Hatcher and Steve Loughran, Manning Publications
Java Performance Tuning, Second Edition, Jack Shirazi, O’Reilly
Patterns of Enterprise Application Architecture, Martin Fowler, et al., Addison-Wesley
最有用的Java社区开发的技术
Apache Ant 1.5, The Apache Ant Project
Eclipse 2.1, Eclipse.org
Tomcat 4.1, The Apache Jakarta Project
Most Innovative Java Product or Technology
AspectJ 1.0.6, Eclipse.org
Eclipse 2.1, Eclipse.org
JavaServer Faces, Java Community Process (Java Specification Request (JSR) 127)

　　　　　　　　　　　　　　　　彭晨阳
　　 本月Java界最令人鼓舞的事，莫过于EJB 3.0雏形已定，2004年5月6日，EJB总设计师Linda DeMichiel在吵闹的TSS年会上（http://www.theserverside.com/symposium/）首次公布了EJB 3.0的重大改变。
　　 EJB 3.0总体目标是易于开发。自从EJB 1.0出来后，曾经遭受了很多人的抨击，后来总算推出EJB 2.0，改正了以前不少问题，特别是性能问题，但是和.NET相关技术相比，EJB难于学习和使用已经成为EJB或J2EE发展壮大的致命危险。
　　 在这个关键时刻，EJB标准委员会经过9个多月的努力，听取了各方面意见，特别吸取了开源领域的轻量编程模型思想，推出了EJB3.0新构想，EJB 3.0最主要有以下几个特点：
　　 首先易于开发使用，目前的EJB对于程序员来说是重量的，因为程序员建立一个EJB需要很多步骤：建立几个接口文件和一个配置文件。
在EJB3.0中，建立一个Session bean将会非常简单，如下：
@Session public class HelloWorldBean {
　　 public void sayHello (String s) {
　　 　　 System.out.println(“Hello:”+s);
　　 }
}
　　 其次，引入Dependency Injection 模式（一种新的Ioc模式，也是AOP基础模式）替代了JNDI的LookUp，这样使得在EJB容器外测试程序变得更加容易。
　　 最后是简化了持久层实体Bean CMP，现在EJB中的实体Bean CMP因为重量且复杂被很多程序员指责甚至攻击，因此，开源项目Hibernate成为很多程序员的新宠儿，EJB 3.0吸取了Hibernate和TopLink轻量特点，简化了CMP，从而使得EJB 3.0的CMP足以在持久层技术和Hibernate之类ORM产品形成了竞争。
　　 Gavin King通过Hibernate启动了J2EE持久层技术的选择之争，Gavin King最近在他的Blog（http://blog.hibernate.org/cgi-bin/blosxom.cgi/）中又对JDO发动了“无情的批判”，他认为JDO存在很多缺点，需要重写，但是相比重写JDO， EJB 3.0 的实体Entity 更接近ORM解决方案。同时，三个主要的J2EE应用服务器厂商（BEA, IBM和Oracle) 都拒绝了JDO 2.0。这些厂商认为：EJB3.0应该实现更简单的持久层模型，对于J2EE没有必要使用另外一套持久层模型。（因此,CMP将继续成为EJB 3.0的持久技术，实体Bean Entity Bean将被继续保留）
　　 Gavin King本人目前效力于JBoss组织，从事JBoss的CMP引擎优化工作，从一个方面说，他同时也正把他在持久层技术上出色的才智贡献到CMP标准实现上。虽然Hibernate没有成为EJB 3.0持久层标准层技术，但是，Gavin King本人无疑是最值得尊敬和崇拜的。
　　 有关EJB 3.0热烈讨论目前还不断在继续，英文讨论可见TSS的专门网址：http://www.theserverside.com/news/thread.tss?thread_id=25779，中文讨论可见：http://www.jdon.com/jive/article.jsp?forum=16&thread=13853。
　　 在EJB 3.0雏形公布之前，Java社区盛行各种排斥EJB的思想和言论，其中不乏各种原因，其中一个主要原因是，EJB产品曾经是昂贵和贵族的代名词，而EJB标准委员会主要成员是世界上除微软以外的最大几个软件厂商，开源社区的矛头是直接指向这些商家。甚至EJB的开源项目JBoss也未被幸免，被一些极端粉子讥讽为傀儡。
　　Rod Johnson是反EJB方面一个代表人物，他创建了著名的开源项目Spring，这个基于AOP的开源框架最终目标是取代EJB，Rod Johnson在这次TSS年会专门开办了讲座：J2EE without EJBs，目前Tomca+Spring+Hibernate逐渐成为J2EE开发者偏好的一种架构选择。
　　其实，现在的EJB难于使用是促使现在的程序员另结新欢的主要原因，也许EJB标委会注意到了这个问题，因此同样也在这次年会上首次公布了EJB 3.0雏形，这总算让EJB支持者大舒了一口气，他们也发表了自己的看法，见下列网址：http://radio.weblogs.com/0135826/2004/05/09.html#a27。
　　所以，这次TSS年会也算开得惊心动魄，Java社区各种思潮都集中在这里碰撞，当然，这些对于喜欢清静的一些国人看来可能过于喧闹，特别是那些在Java门口观望的程序员可能感到担心，是不是Java技术有问题啊，怎么没有一个让人可以放心选用的技术啊？是否可以等到Java社区争论完毕，再进入Java世界呢？
　　其实，这是一种误解，没有完美的技术，只有合用的技术，争论代表活力和希望，Java社区的吵闹正体现了Java世界的开放和自由，在Java社区，开发者可以真正自己当家作主，可以自己根据实际情况选择适合自己的技术，难道你愿意放弃这种自主的选择权吗？
直接来源：【J道】http://www.jdon.com/artichect/EJB3.0.htm

　　很久以前就有这么一个感觉，就是觉得某个场景曾经经历过，甚至认为这个场景很熟悉之后，能够感觉应该怎么发展，结果就这么发展了。
　　高中做英语阅读的时候有一篇文章似乎提到过这种事情，可惜也没有结果。
　　最近的一件事情，和梦有关的。
　　大家都知道，Java1.2之后，基于商业目的都成为Java2，我有一天做梦，梦到大家谈论的都是Java5，那天去图书馆看《程序员》，说是JDK1.5出来了，要改为JDK5.0，我当时就觉得太……诡异了。也不知道Sun是否有打算改成Java5，呵呵，那以后就是J5EE了：）不过从J2SE5.0来看，Sun是没有这样的打算了；Ｐ
　　不过新的EJB3.0倒是给人感觉不错，偏向轻量的发展方向感觉挺好。

　　这篇文章的标题中的“知更鸟”吸引了我的眼球，但是这文章的内容却更让人深思。
【故事】
20世纪初，英国的乡村有一套牛奶配送系统，将牛奶送到顾客门口。由于牛奶瓶没有盖子，山雀与知更鸟常常毫不费力，便在顾客开门收取牛奶前，先一步享用。后来，随着厂商加装了铝制的瓶盖，山雀与知更鸟便不再拥有这“免费早餐”。
但到了50年代初期，当地的所有山雀（约100万只）居然都学会了刺穿铝制瓶盖，重开“免费早餐”的大门。反观知更鸟，却只有少数学会，始终没有扩散到其余的大多数。
很明显，山雀经历了组织学习的过程，藉由个体的创新技能，传送给群体成员，成功增加了族群对环境的适应力。但问题是，为什么山雀可以，而知更鸟却不能呢？生物学家发现，山雀在年幼时期，就已习惯和同类和平相处，甚至编队飞行。而知更鸟则是排他性较强的鸟类，势力范围内是不允许其他雄鸟进入，同类之间基本上是以敌对的方式沟通。因此，虽然两者同属鸟类，但和谐相处的山雀，比起互相敌视的知更鸟，更能学习互助，进化程度更高。
【管理启示】
在一个群体之内，如果内部竞争太激烈，成员之间互相争位敌视，是难以发展成一个学习型组织。要成为学习型组织，先决条件是必须有和谐的内部气氛，组织内的成员才能互相分享知识。有些企业的管理人误以为内部竞争越强越好，甚至刻意制造很强的竞争文化，自以为这是高明的管理手段，殊不知只是在带领企业步知更鸟的后尘!
【成片的大树点评】
1、 在事关生存的事情上，团结是最好的致胜法宝。
2、 经常交流会提高团队的整体水平，每个人的技术点并不相同，通过交流可以更加丰富大家的知识,增强团队的力量。
来源：成长的大树，其中的【管理故事】蛮好的。
http://blog.csdn.net/lxf428/archive/2004/09/14/103907.aspx