在我做過的很多項目的過程中，我一直有一個懸而未決的問題在困擾我，那就是持久層的開發。持久層的開發一般來說要么用CMP，要么用JDBC＋DAO。 CMP就不用說了，它對我來說是一種失敗的實踐，而JDBC+DAO也存在很多的困難，我很難做到把關系表記錄完整的映射到持久對象的關系上來，這主要體現在多表的關系無法直接映射到對持久對象的映射上來，可能是一個表映射多個持久對象，有可能是多個表映射一個持久對象，更有可能的是表的某些字段映射到一個持久對象，但是另外一些字段映射到別的持久對象上。而且即使這些問題都處理好了，也不能直接按照對象的方式來對持久對象（PO）編程，因為存在1：N關系的持久對象的查詢其實就是1+n次對數據庫的SQL，我曾經有一次失敗的持久層設計，結果是某個關聯很多其它持久對象的PO一查詢就是5n＋1次 sql，速度慢的不得了，最后不得不整個修改底層設計，最后等于是完全拋棄了對象設計，完全是按照表字段進行操作。
但是這樣做非常難受，因為系統的設計是從需求設計，系統設計這樣自頂而下的，結果都到了詳細設計階段了，被持久層映射問題限制，不得不自底向上修改設計方案，又回到了按照過程進行編程的老路上來，非常的糟糕。
我對這個問題思考了很久，最后終于意識到這其實是一個很經典的問題：對象和關系的映射問題。實際上自從OOP編程流行以后，就存在這個難題了，所以才有人提出關系數據庫進行重新設計，改用對象數據庫，但實際上關系數據庫并沒有被淘汰，于是就只能在上層的應用層找解決方案。這時候我明白了我需要的實際上是一種 ORM 產品。
我最早想到的ORM就是JDO，于是我下載了兩個JDO產品，準備認真的學習一下，但是研究了一段時間之后，我發現我對JDO非常的失望，原因如下：
1、JDO沒有一個好的開源免費實現，好的產品都是商業產品，并且在國內沒有銷售和技術支持。這就造成了JDO只有學習之用，不能把它用在實際項目中，否則的話，你把軟件賣給客戶的時候，還要告訴他，你還要另外去買一個國外的軟件產品，并且在國內沒有技術支持，出了持久層的問題，我們也解決不了，請你自己打國際長途去解決問題，你認為客戶能答應嗎？
2、JDO不是一個輕量級封裝，它試圖建立一個完整的持久層框架，但是還很不完善，造成了JDO 感覺比較笨重，很多操作方式令人覺得煩瑣和古怪。這加重了程序員學習和編程的負擔，而且封裝的太多會造成一個嚴重的問題就是一旦出現報錯信息，調試起來非常困難，你很難準確的定位錯誤究竟出在哪里，封裝的越輕，問題越容易定位，越容易解決，封裝的越重，問題越復雜，越找不到原因，CMP就是一個很好的例子，出了錯誤，調試起來非常困難和麻煩。
3、JDO的標準很不完善，存在重大缺陷。最主要的問題體現在PO不能脫離PM（相當于 Hibernate的Session）而存在，這是個非常嚴重的問題，會造成編程的時候進行大量VO的拷貝操作，煩瑣極了；另外一個重大缺陷是靜態的 POJO的Enhancer，不能運行期動態Enhance，無法進行增量編譯和調試，編程和調試起來非常煩瑣，每次都要手共運行一個工具對POJO進行 Enhance；此外還有一些缺陷，例如JDOQL不完善，映射關系的表達不夠強大等等。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
