下面新生代代表JDO隆重登场，JDO绝对属于超年轻选手，　JDO1.0也不过是2002四月份才发布。2003五月份出台1.0.1,　目前最新2.0草案已经发布。就为这2.0，江湖上展开的讨论可以说是“血雨腥风”，两大兵团，JDO兵团和EJB兵团争得是不可开交。有兴趣的不妨去瞧瞧，里面也不乏重量级人物。单从这一点来看，它能对EJB产生这么大的冲击，足以说明了这个初生牛犊确有过人之处。JDO的诞生给java数据持久性带来很多新特性，特别是它弥补了EJB对OO编程的先天不足，JDO提供了完全的OO支持，继承，多态。JDO和　EJB比属于轻量级工具，无需容器支持。不像EJB，要用你就非得整一个Weblogic,　webSphere之类的。

　　JDO的简单易用是最为人们所称道的，不需要你写大量无用的接口，不需要你继承什么特殊的类，唯一所要做的就是对你的class文件做一下enhance。用了JDO,可以说我们的java程序这下真正OO了，我们无需再理会数据库里面有啥表格了，存取都是以java　object为对象了，所有数据库表格都是自动生成的。这一点可以说也是一个革命了。

　　在此之前，项目设计阶段，Database　Schema设计可以说是个重头戏。而现在用JDO开发，完全不需要数据库设计了。那你的Database　Schema呢？就是你的Class啊，JDO会根据你的Class自动生成相应的数据库表格。一个字，爽！从数据库可移植性来看，JDO也是优势明显，就我使用过的Kodo　和　Genie来看，几个简单应用程序换数据库时候除了换一个JDBC　driver,　换一下数据库URL,无需对程序做任何改动。　这一点对EJB　来说又是处于劣势。从家庭出身来看，JDO也是出生名门，从一开始就处于JCP管理之下。从企业级支持来看，它可以很好的和Session　bean协同工作，对于企业级开发，Session　bean　+　JDO的方式是Session bean+entity方式的一个强有力竞争对手。虽然有这么多优点，不过它的发展之路也非一帆风顺，这不，今年五月份JDO2.0的投票，IBM、Oracle、Bea三大巨头同时投了反对票。不过稍微一想，就可以理解，这并不是JDO本身技术有什么重大缺陷，而是JDO动到这些巨头们的奶酪了。

　　Bea、IBM做着业界最为著名应用服务器，weblogic和WebSphere,在EJB上面是投下了血本了，他们不能眼睁睁看着JDO来蚕食EJB市场。而Oracle,　还在卖着它自己的O/R工具Toplink,　看着JDO日渐强大，他能不着急么。不过呢，公司再牛，他也挡不住历史前进的车轮吧，最终JDO2.0的投票还是以绝对的票数（12：3）通过了。

　　还有其它散落江湖的Java持久化技术，如Hibernate、Castor、Toplink，他们虽然没有皇家血统，不过实力也是不容小视。就拿Hibernate来说，是javaworld评选出来的2003年度最佳java数据存取工具，目前可以说是大红大紫。而Castor和Toplink也算是历史悠久了，在JDO没有出世之前，它们就在江湖上混着了。目前也占据着一定的市场。这些第三方的工具从功能上来说很类似于JDO,　只是各自的API互不相同。这也是后来JDO规范的呼声越来越高的一个原因吧。这些第三方O/R　mapping工具能在江湖上立足，也确实都有各自过人之处。如Hibernate金字招牌就是Open　Source，支持几乎世面上所能看到得绝大部分数据库，并且文档也非常齐全。Toplink么，可谓历史悠久，又榜着Oracle这棵大树。目前来看，这些工具也占据着java数据库存取的不小市场。个人觉得，随着JDO规范的不段完善，JDO产品的普及，这一部分人员可能会在以后渐渐退出历史舞台。不过从Hibernate目前如日中天的气势来看，好像说这句话还为时过早。

　　关于这些技术优劣之争从它们刚刚出生那天起从来就没有停止过，而各家各派也从来没有能够说服过对方。对于我们应用开发者而言，撇开应用纯粹来争论技术优劣并没有多大意义。还是俗话说的好，没有最好的，只有最合适的。我们能够在做开发的时候能够选择一个最合适于自己应用的技术，那就足够了。总的来说，JDBC面向RDBMS,比较适合关系数据库模式驱动的应用，例如统计表格数据，生成报表之类的应用。EJB　技术以J2EE应用服务器为中心，如果你的应用确实需要灵活的可声明的事务边界，需要支持大容量的访问和不间断的服务，需要应用服务器的集群，那么选EJB吧。JDO则面向对象，对于以域对象为中心的应用，包含图，树模型的应用，JDO是首选。

 
　
说明：本教程来源互联网或网友上传或出版商，仅为学习研究或媒体推广，wanshiok.com不保证资料的完整性。
　

 2/2   首页 上一页 1 2