Java数据库存取技术
程序员文章站
2023-12-11 17:47:52
it技术日新月异，新技术的出现令人目不暇接，似乎每一天都在产生着新名词。不过归根结底it所要实现的价值不外乎数据收集，然后再以客户希望的形式展示给客户而已。因此数据存取技术...
it技术日新月异，新技术的出现令人目不暇接，似乎每一天都在产生着新名词。不过归根结底it所要实现的价值不外乎数据收集，然后再以客户希望的形式展示给客户而已。因此数据存取技术也就成了一个永恒的话题。而在java这个开放的世界里，数据库存取技术是五花八门，种类繁多。我们也来侃侃java世界里主流的数据库存取技术。
首先列出英雄榜
1．jdbc直接访问数据库
2．ejb entity bean.
3．jdo技术。
4．第三方o/r工具，如目前大红大紫的hibernate, 其它如castor, toplink.
先说说这个历史最为悠久的jdbc吧。从java诞生的那天起，这位仁兄就开始登上历史舞台了。java能有今天这么风光，jdbc可以说是功不可末。一路走来，如今已是jdbc3.0了。在没有jdbc的时候，访问数据库那是八仙过海，各显神通，各家数据库厂商都有自己的一套api, 苦就苦了开发人员了。换了个数据库，那个程序要改是面目全非。
jdbc规范的出台，向世界宣告从此有了访问关系数据库的标准通用接口了。jdbc标准获得了几乎所有数据库厂商的支持，好像还真难找到这么一个数据库，它是没有jdbc支持的。jdbc规范一经发布，获得了空前成功，很快成为java访问数据库的标准。jdbc的成功在于它的规范统一标准的接口，只需要掌握标准的sql语言就可以访问各种不同的数据库了。这种数据库间的可移植性和java一直高喊的口号compile once, run everywhere遥相呼应。jdbc今天还是java访问数据库的基石，cmp、jdo、hibernate说到底只是更好的封装了jdbc, 提供了更为上层的更为强大的接口而已。然后说说jdbc直接访问数据库的方式来实现java 持久性。
这种方式相对于cmp来说比较简单直接，特别是对于小型应用十分方便。比如，我要写一个简单的留言版程序，就没有必要session bean ,entity bean ，又是home接口又是远程接口，一层层调了吧。直接jdbc,写sql语句了事。和其它持久化技术相比，jdbc直接访问数据库的方式需要程序员操心的事情多了一些，你得自己关心transaction, 自己关心连接池，你得写大量的get set方法，把sql select出来的值一个一个塞到你的java object中，或者把java object的值一个一个给取出来，用sql insert 到数据库，完全手动进行o/r mapping。为了克服这些缺点，cmp, jdo等等开始陆续登上历史舞台。
下面ejb登场，ejb作为sun j2ee体系的核心部分，是sun 所力推的企业级开发的首选，而ejb entity 目前仍然是sun j2ee白皮书所最为推荐的java持久化技术。entity bean作为ejb规范的一部分，也是ejb规范里面最备受争议的一种技术，它伴随着ejb规范走过了风风雨雨几个春秋。目前ejb3.0规范草案已经出台，http://jcp.org/en/jsr/detail?id=220。
从家庭出生来看，ejb可谓是根正苗红，规范处于 jcp管理之下，拥有超级豪华的专家组成员， sun、ibm、oracle、borland、bea、sap、jboss、apache软件基金组织等等。单从这一点来看，选它作为企业级开发，技术支持应该就无需担心了。当然向ibm, bea等寻求项目咨询价格当然也不菲。从提供功能上来看，ejb entity经历了ejb1.0，ejb1.1，ejb2.0，功能也越来越完善了。包括了完善的事务支持，ejbql查询语言，透明的分布式访问等等。不过作为一个重量级技术，entity bean的性能不太尽人意，这成为它备受争议的一个焦点，不知在3.0以后这个状况会不会有所改进。
再有一个，它功能虽然强大，可是对于易用性来说，实在不敢恭维，写一个最简单的bean，也非得home接口，远程接口，要再加上2.0以后加入的本地接口，这么林林总总一大堆，足以让java初学者望而却步了。但是这一点在一段时间内竟然也成了ejb功能强大，技术高深的“佐证”。记得多年以前刚毕业那阵，ejb应用在国内还比较少，公司里也没有人研究why ejb这个问题，反正凡是用ejb的项目就是牛项目，用ejb的人就是牛人，分到ejb项目组的兄弟们走路都是抬头挺胸的，说话都比我等还在jdbc, sql的人要高两嗓门。ejb 技术目前盘踞着企业级应用的大部分*，老大地位短时间内很难捍动。
下面新生代代表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是首选。
首先列出英雄榜
1．jdbc直接访问数据库
2．ejb entity bean.
3．jdo技术。
4．第三方o/r工具，如目前大红大紫的hibernate, 其它如castor, toplink.
先说说这个历史最为悠久的jdbc吧。从java诞生的那天起，这位仁兄就开始登上历史舞台了。java能有今天这么风光，jdbc可以说是功不可末。一路走来，如今已是jdbc3.0了。在没有jdbc的时候，访问数据库那是八仙过海，各显神通，各家数据库厂商都有自己的一套api, 苦就苦了开发人员了。换了个数据库，那个程序要改是面目全非。
jdbc规范的出台，向世界宣告从此有了访问关系数据库的标准通用接口了。jdbc标准获得了几乎所有数据库厂商的支持，好像还真难找到这么一个数据库，它是没有jdbc支持的。jdbc规范一经发布，获得了空前成功，很快成为java访问数据库的标准。jdbc的成功在于它的规范统一标准的接口，只需要掌握标准的sql语言就可以访问各种不同的数据库了。这种数据库间的可移植性和java一直高喊的口号compile once, run everywhere遥相呼应。jdbc今天还是java访问数据库的基石，cmp、jdo、hibernate说到底只是更好的封装了jdbc, 提供了更为上层的更为强大的接口而已。然后说说jdbc直接访问数据库的方式来实现java 持久性。
这种方式相对于cmp来说比较简单直接，特别是对于小型应用十分方便。比如，我要写一个简单的留言版程序，就没有必要session bean ,entity bean ，又是home接口又是远程接口，一层层调了吧。直接jdbc,写sql语句了事。和其它持久化技术相比，jdbc直接访问数据库的方式需要程序员操心的事情多了一些，你得自己关心transaction, 自己关心连接池，你得写大量的get set方法，把sql select出来的值一个一个塞到你的java object中，或者把java object的值一个一个给取出来，用sql insert 到数据库，完全手动进行o/r mapping。为了克服这些缺点，cmp, jdo等等开始陆续登上历史舞台。
下面ejb登场，ejb作为sun j2ee体系的核心部分，是sun 所力推的企业级开发的首选，而ejb entity 目前仍然是sun j2ee白皮书所最为推荐的java持久化技术。entity bean作为ejb规范的一部分，也是ejb规范里面最备受争议的一种技术，它伴随着ejb规范走过了风风雨雨几个春秋。目前ejb3.0规范草案已经出台，http://jcp.org/en/jsr/detail?id=220。
从家庭出生来看，ejb可谓是根正苗红，规范处于 jcp管理之下，拥有超级豪华的专家组成员， sun、ibm、oracle、borland、bea、sap、jboss、apache软件基金组织等等。单从这一点来看，选它作为企业级开发，技术支持应该就无需担心了。当然向ibm, bea等寻求项目咨询价格当然也不菲。从提供功能上来看，ejb entity经历了ejb1.0，ejb1.1，ejb2.0，功能也越来越完善了。包括了完善的事务支持，ejbql查询语言，透明的分布式访问等等。不过作为一个重量级技术，entity bean的性能不太尽人意，这成为它备受争议的一个焦点，不知在3.0以后这个状况会不会有所改进。
再有一个，它功能虽然强大，可是对于易用性来说，实在不敢恭维，写一个最简单的bean，也非得home接口，远程接口，要再加上2.0以后加入的本地接口，这么林林总总一大堆，足以让java初学者望而却步了。但是这一点在一段时间内竟然也成了ejb功能强大，技术高深的“佐证”。记得多年以前刚毕业那阵，ejb应用在国内还比较少，公司里也没有人研究why ejb这个问题，反正凡是用ejb的项目就是牛项目，用ejb的人就是牛人，分到ejb项目组的兄弟们走路都是抬头挺胸的，说话都比我等还在jdbc, sql的人要高两嗓门。ejb 技术目前盘踞着企业级应用的大部分*，老大地位短时间内很难捍动。
下面新生代代表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是首选。