Hibernate在不?q的旉里，从一个不L(fng)的开源Y件发展到今天令业界瞩目的LO/R Mapping框架QGavin King从一个开源Y件的作者成Z界D重的人物Q这多少有些传奇的色彩。毕竟，单纯从技术成p言QHibernate不算是最有成qJava开源框架YӞ到目前ؓ(f)止也不是一个完无~的软gQ从个h技术水q言QGavin King也不绝剙手?/P>
在当前的Java持久层框架中Q最行的O/R Mapping产品分别是HibernateQJDO和TopLink?/P>
自从dGavin King加入JBoss之后QHibernate已经׃个民间的开源Y件走上了兼容EJB EntityBean的道路。然而更加o(h)Z目的是，Gavin King在EJB3.0 EG中充当了一个非帔R要的角色Q只要对比一下EJB3.0的EntityBean和Hibernate3Q真相就?x)大白，虽然API接口不同Q但?EntityBean的设计理念完全来自于Hibernate?/P>
虽然EJB3.0的EntityBean在相当程度上来源于HibernateQ但是毕竟是不同的API接口Q因此Hibernate和EJB3.0 EntityBeanI竟是怎样的一U关p，是很多h心中的疑问?/P>
2004q四月䆾JBoss的Ben Wang访华期间Q我曄向B(ti)enhHibernate的未来发展，他回{说QHibernate未来仍旧以独立的Y件品存在和发展Q既可以 outside EJB container使用Q同时Hibernate也将做ؓ(f)JBoss EntityBean ImplementationQ又可以inside EJB container使用。然而如何既insideQ又outsideQ终I缺乏一个感性的认识?/P>
10?日JBoss发布的EJB3.0 PR揭开了答案。从Sourceforge的CVS服务器上面checkout出来源代码看一下，我们可以发现QGavin King对Hibernate3q行了简单的装Q将EJB 3.0 EntityBean API调用转换为内部Hibernate3自己的APIQ从而实现EJB3.0 EntityBean的兼宏V?/P>
EJB3.0不承d器调用，如果你想享用EJB3.0Q则必须q行在某个EJB Vendor提供的容器内Q例如你使用JBoss提供的容器，那么你调用的是EntityBean APIQ这些调用请求会(x)被{换ؓ(f)Hibernate API的调用请求。这意味着Hibernate实际上提供了两套APIQ一套是Hibernate原生APIQ另一套是兼容EJB3.0 EntityBean API。对于那些需要分布式调用支持Q需要EJB容器的开发h员来_(d)他们选择后一套APIQ对于不需要EJB容器的开发h员来_(d)他们选择前一?API。这是Hibernate既定的发展策略?/P>
今年夏天投票通过的JDO2.0标准从某U程度而言Qƈ不逊色于Hibernate当前的版本，有些功能甚至比Hibernateq要好，例如 JDO支持对类属性的lazy loadingQ而Hibernate要到3才支持，当前Hibernate仅仅支持cȝlazy loading。实际上在去q_(d)已l有很多用户不断提出对类属性的lazy loading的需求，然而Gavin King当时一直不认ؓ(f)q个需求有d的必要性。再例如被Gavin King形容为“可憎的”JDOQLQ实际上是类SQL查询语言和对象条件查询的混合体。从功能上来_(d)不如HQL强大Q但是比Hibernate自己的条件查询强?/P>
不知道究竟出于什么原因，Gavin King对JDOg一直怀有由L(fng)厌恶Q?月，他在Hibernate的blog上面对JDOq行了毫不留情的批判Q列举了JDO的种U缺Ҏ(gu)解释Z么EJB3持久层规范没有把JDO考虑q去。然而事实上他的批判充满了对JDO的误解和偏见Q例如Gavin King憎恨JDOQL丝毫没有什么特别的理由Q只因ؓ(f)JDOQL不是一个纯_的查询语言Q而是一个合体Q这多少让h对Gavin King的风度感到遗憾。在被SolarMetric的Abe White反驳之后Q同h有风度的_(d)“我可没有时间做q种无谓的争论，事实上每个h都认Z自己的技术是最好的……我是错了，JDO那伙Z错了Q每个h都会(x)犯错误……”。（所以说人无完h阿！Q?/P>
JDO2规范的出C实上构成了对HibernateQ乃臛_于Hibernate理念的EJB3.0 EntityBean的严重威胁。JDO1.0规范在功能上的严重缺失导致了JDO无力面对Hibernate和TopLink的竞争，然而功能基本完备的JDO2挟众多JDO Vendor商业支持的合力，同时JDO规范可以避免产品锁定在某个Vendor的优势，已经竞争的天^拉直?/P>
然而JDO2和EJB3两大商业L标准的分裂，是大部分人，甚至包括厂商所不希望看到的?于是最lEJB3的Lead Linda DeMichiel和JDO2的Lead Craig Russell联名发表公开信，宣布了一个合qEJB3和JDO2持久层规范的计划Q新的持久层规范?yu)以JSR-220(EJB3.0)的持久层规范为基Q融合JDO2的部分特性。新的持久层规范?yu)进入J2EE1.5之中Q独立于EJB存在Q既可以inside J2EE容器来用，也可以脱J2EE容器Q独立的q行?/P>
q个新的持久层框架可以说完全是一个政ȝ产物。EJB VendorsZ自n利益反对JDOQ得JDO没有办法成ؓ(f)J2EE的一部分Q然而标准的分裂也是大部分h更加不希望看到的Q于是最lJDO成了政治斗争的牺牲品。从表面上来看，JDO和EJB3.0 EntityBean都将被新的持久层框架取代Q似乎JDOq没有吃亏，但实际上JDO2标准已经成熟Q部分JDO领导厂商的品已l蓄始待发，?EJB3.0 EntityBeanq处于Early DraftQ等待品诞生至也是一q之后的事情了；另外值得耐hd的是Q新的持久层框架基于当前EJB3.0 EntityBeanQ再l合JDO2的规范，q且处于EJB3.0 EG的控制之下，再加入一些JDO2 EG的成员。因此可以看出来新的持久层框架无疑还是以EJB3.0 EGZD行制定的?/P>
从长q来看，EJB3和JDO2的政L争对双方都有好处Q长期分裂带来的后果对双方的发展都不利，然而从短期来看QJDO2实是在q场政治斗争中|下阵来。最直接的体现就是，已经有一些JDO的用户对JDO的前景生了动摇和迷茫，不少的JDO爱好者更是直aJDO死?/P>
TopLink是一个老牌的O/R Mapping软g了，自从被Oracle收购之后Q又增加了对Oracle数据库的良好支持Q和对Oracle AS EntityBean的支持。Oracle提供了TopLink的图形设计环境，可以使得设计好的TopLink域模型既可以被单独用在TopLink 中，也可以被用在EJB CMP中。因此看来TopLink也走了一条和Hibernate同样{略的\?/P>
TopLink的问题在于相比Hibernate的开源和免费的优势来_(d)TopLink既不开源，售h(hun)又不菲上。本来商业Y件TopLink应该在技术支持和商业宣传{略上拥有够的优势Q然而Oracle公司毕竟是一个以数据库ؓ(f)核心产品的公司，其他的一切品都是ؓ(f)了数据库销售业l而服务的。在Oracle产品U中处于一个从属地位的TopLinkQ由于先天不I只能眼睁睁看着Hibernate的日益壮大而无所作ؓ(f)Q因?TopLink更多的被局限在购买了Oracle数据库，q且l定Oracle数据库的用户体中?/P>
J2EE1.5的新持久层规范将毫无(zhn)念的成为未来持久层框架的主APIQ无论是HibernateQJDOQ还是TopLinkl将兼容q个L商业API。在当前的这三种持久层API当中QHibernate无疑是最有前途的。这是因为：(x)
1、新的持久层规范?yu)基于EJB3.0 EntityBean规范Q这意味着仍将以Hibernate的设计理念ؓ(f)基础
2、JBoss对EJB3.0规范跟随的步伐非常紧密，在规范制定过E中׃断的发布参考实C品，因此可以对对EJB3.0规范产生比较大的影响力?/P>
lg所qͼ我们有理由对Hibernate的前途抱有强烈的信心?/P>
最后的一个疑问是Q既然J2EE1.5的新持久层框架可以脱J2EE容器q行Q那么大家不全部都去用Hibernate的后一套兼容APIQ而完全放弃Hibernate的原生API了吗Q那么是否意味着Hibernate做ؓ(f)一个独立品的使命dl结呢？
对于q个问题我的看法是：(x)J2EE1.5的持久层规范要综合各个EJB VendorQJDO Vendor的意见，要^衡他们之间的利益得失Q那么这样一个瞻前顾后的规范必然无法覆盖所有应用场合的全面需要，q不像Hibernate的原生API 可以随时Ҏ(gu)开发h员的要求增加功能那么灉|。因此我预计Hibernate的原生API以其更加强大的功能仍然会(x)吸引一大批人直接用原生APIQ而不是兼容J2EE规范的API?/P>
总而言之，对于我们当前的持久层开发来_(d)最好的办法莫过于坚定的使用DAO层来隔离持久层和业务层逻辑Q那么不未来持久层风云如何变换Q但凡基于POJO的持久层框架都可以被我们拿来L替换
]]>
]]>
]]>