網上關于JDO的文章已經不少了，關于JDO的優點也講了很多，我看了一些文章后，自己也研究了一段時間，忽然很想寫一個系列文章全面的介紹一下JDO，今天先寫下第一篇算是個開頭。呵呵，有些內容是我對JDO規范的理解，如果有不對的地方請大家指正。
Java開發人員已經有好幾種存取數據庫的方法：序列化，JDBC，面向對象映射工具，對象數據庫，以及實體EJB。那為什么還要介紹其他的存儲架構呢？答案是，上面每一種實現存儲的方案都存在一定的限制。JDO正在嘗試解決這些限制。
序列化 是Java建立的一種傳輸機制，它能夠把對象的信息轉換成一系列的字節碼，這些字節碼可以可以被傳輸到網絡或者存儲到一個文件中。序列化的使用非常簡單，但他還是有限制的。它必須立即存取對象的特征，而且它不適合存取大批量的數據。在它更改一個對象的屬性時如果有錯誤發生他不能回滾錯誤的修改，因此不適于應用程序的數據完整性要求。多個線程或程序不能同時互不干擾的讀寫序列化數據。所有這些不足是的序列化無法滿足大多數數據存儲要求。
許多程序員使用 JDBC API來操作關系數據庫。JDBC克服了許多序列化中存在的缺點：它可以操作大批量的數據，有確保數據一致性的機制，支持信息的并發存取，可以使用已經非常成熟的SQL語言。不幸的是，JDBC使用起來并不像序列化那么簡單。JDBC使用的關系范例不是被設計用于存儲對象的，因此，它迫使你放棄代碼中使用面向對象程序存儲數據的可能。
由軟件廠商創建的架構可以為你實現對象和關系數據庫之間的映射。 這種對象-關系映射支持可以是的你專注于對象模型的設計而不必關心面向對象和關系數據庫之間的匹配。不幸的是每一種對象-關系映射支持都有一套他自己廠商實現的API。你不得不使自己的代碼遷就某一個單獨廠商的實現。假如這個廠商提高價格或者停止對bug更改的支持，如果你想用其他的廠商實現架構時，你就不得不重寫你的代碼。
比對象關系數據庫映射更好的是，一些軟件廠商開發了一種新的存儲對象到數據庫的方法。這種對象數據庫使用起來常常比對象關系映射軟件簡單。ODMG組織成立的目的就是創建一個訪問對象數據庫的標準API。一些廠商也尊崇ODMG組織的要求，因此由于廠商實現不同帶來的麻煩也解決了。一些公司對于從關系數據庫轉向對象數據庫顯得猶豫不決，因為有大量的數據存儲在傳統的關系數據庫中。個別數據庫分析工具可以用于對象數據庫，然而大量的數據存儲使用的仍然是關系數據庫。由于這些原因，對象數據庫被很好的利用。
Java平臺的企業級應用中引入了實體EJB。 實體EJB是一個組件，他描述了數據庫中的持久性數據信息。EJB使用類似于“對象-關系”映射的辦法，它提供了一個持久性數據的面向對象的表示。不同于對象關系軟件，EJB對于關系數據庫沒有限制；它描述的持久性信息可以來自一個企業信息系統（EIS）或者其他的存儲設備。而且，EJB使用了一個嚴格標準，實現它的廠商必須遵循這個標準。不幸的是，EJB標準在面向對象方面稍微有些欠缺，比如一些高級的特性：繼承、多態和復合關系等。另外，EJB的代碼編寫很復雜，而且它是一個重量級組建需要消耗應用服務器很很多的資源來運行。但是，EJB中的會話Bean和消息驅動Bean有很多優勢，所以JDO規范詳細定義了JDO如何與他們進行集成。
JDO集成了很多上述持久性機制的特性，這使得在JDO中創建一個持久類就像創建一個序列化類一樣簡單。JDO還支持批量數據的存儲，數據一致性，并發處理和JDBC的查詢功能。就像“對象-關系”映射軟件和對象數據庫一樣，它允許使用面向對象的高級概念，比如“繼承”。它避免了像EJB中實體Bean一樣必須依賴于來自廠商定義的嚴格規范的限制。像EJB一樣，JDO也不限定任何特定的后端數據庫。
但是，這里還是要說一下，世界上從來就沒有“萬靈丹”。所以，JDO并不是對于每一個應用程序都是有好處的。很多應用程序完全可以使用其他更理想的存儲機制。