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目前如日中天的氣勢來看，好像說這句話還為時過早。

　　關于這些技術優劣之爭從它們剛剛出生那天起從來就沒有停止過，而各家各派也從來沒有能夠說服過對方。對于我們應用開發者而言，撇開應用純粹來爭論技術優劣并沒有多大意義。還是俗話說的好，沒有最好的，只有最合適的。我們能夠在做開發的時候能夠選擇一個最合適于自己應用的技術，那就足夠了?？偟膩碚f，JDBC面向RDBMS,比較適合關系數據庫模式驅動的應用，例如統計表格數據，生成報表之類的應用。EJB　技術以J2EE應用服務器為中心，如果你的應用確實需要靈活的可聲明的事務邊界，需要支持大容量的訪問和不間斷的服務，需要應用服務器的集群，那么選EJB吧。JDO則面向對象，對于以域對象為中心的應用，包含圖，樹模型的應用，JDO是首選。

　　以上就是Java數據庫存取技術，如果你想知道得更多，更多相關內容請繼續關注錯新技術頻道。