google-app-engine - Google App Engine上的JDO與JPA for Java




(11)

JPA是Sun的持久標準,JDO是IMHO的死亡(實際上,它已經死了,但仍在移動)。 換句話說,JPA似乎是一項長期投資。 所以我想我會選擇JPA,如果兩者對我來說都是新手。

我想用Struts2在Google App Engine上開發我的項目。 對於數據庫我有兩個選項JPA和JDO。 請你們建議我嗎? 兩者對我來說都是新的,我需要學習它們。 所以我會在回復之後專注於一個。

謝謝。


聲稱JDO已死的人不是沒有好處。 以下是我在“專業EJB 3 Java持久性API”一書中讀到的內容:“此後不久,Sun宣布將JDO簡化為規范維護模式,並且Java持久性API將從JDO和其他持久性供應商中抽取出來,並成為單一支持標準前進“。 作者Mike Keith是EJB3的聯合規範領導者。 當然,他是JPA的大力支持者,但我懷疑他是否有足夠的偏見來說謊。

誠然,當這本書出版時,儘管JDO的確擁有比JPA更先進的技術特性,但大多數主要廠商都聯合了JPA而不是JDO。 這並不奇怪,因為EE領域的大公司如IBM / Oracle也是大型RDBMS供應商。 越來越多的客戶在他們的項目中使用RDMBS而非非RDMBS。 JDO一直在死,直到GAE給它一個很大的提升。 這很有意義,因為GAE數據存儲不是關係數據庫。 某些JPA功能不適用於聚合查詢,Join查詢等擁有多對多關係的bigtable。 順便說一句,GAE支持JDO 2.3,而僅支持JPA 1.0。 如果GAE是您的目標雲平台,我會推薦JDO。


去JDO。 即使你沒有這方面的經驗,也不難獲得,你將擁有一項新技能!


在JDO和JPA之間的比賽中,我只能同意數據核海報。

首先,也是最重要的,數據核的海報知道他們在做什麼。 他們畢竟開發了一個持久庫,並且熟悉關係以外的數據模型,例如Big Table。 我確信hibernate的開發人員在這裡,他會說:“我們在構建核心庫時的所有假設都與關係模型緊密結合,hibernate並未針對GAE進行優化”。

其次,JPA毫無疑問被廣泛使用,作為官方Java EE堆棧的一部分有所幫助,但這並不一定意味著它更好。 實際上,如果你閱讀了JDO,它就相當於比JPA更高的抽象層次。 JPA與RDBMS數據模型緊密耦合。

從編程的角度來看,使用JDO API是一個更好的選擇,因為你在概念上減少了很多。 理論上,您可以根據需要切換到任何數據模型,前提是您使用的提供程序支持底層數據庫。 (在實踐中,你很少會達到如此高的透明度,因為你會發現自己在GAE的對像上設置主鍵,並且你將自己綁定到特定的數據庫提供者,例如穀歌)。 它仍然會更容易遷移。

第三,你可以使用Hibernate,Eclipse Link,甚至可以使用GAE。 谷歌似乎已經做出了巨大的努力,讓您可以使用您用來構建應用程序的框架。 但是,當他們將GAE應用程序構建成RDBMS時,人們意識到它們很慢。 GAE的春天很慢。 您可以在此主題上谷歌谷歌IO視頻,看看它是真的。

而且,遵守標準是一件很明智的事情,原則上我鼓掌。 另一方面,JPA成為Java EE棧的一部分,人們有時會失去他們的選擇概念。 如果您願意,可以意識到Java Server Faces也是Java EE堆棧的一部分。 它是Web GUI開發的一個令人難以置信的整潔解決方案。 但最後,為什麼人們,更聰明的人,如果我可以這樣說,偏離了這個標準並使用GWT呢?

在所有這些中,我必須承認JPA有一件非常重要的事情。 這是Guice及其對JPA的便利支持。 看起來谷歌在這一點上並不像往常一樣聰明,並且滿足於現在不支持JDO。 我仍然認為他們可以負擔得起,最終Guice也會吞併JDO,或者也許不會。


JPA是一條走出去的道路,因為它似乎被視為一種標準化的API,並且最近在EJB3.0中得到了推動.JDO似乎失去了動力。


GAE / J將在年底前添加MYSQL。


GAE / J谷歌組織有幾個關於這件事的文章。 我會在那裡搜索,看看人們的意見。 你會得到一個非常不同的信息,以上述意見。 還關注BigTable不是RDBMS的事實。 使用正確的工具來完成這項工作


在撰寫本文時,我認為使用JDO可怕之處在於,唯一的實施供應商是Datanucleus ,其缺點是缺乏競爭導致許多問題,如:

  1. 關於extensions等一些方面的非常詳細的文檔
  2. 你通常會得到作者的諷刺回應,比如(你是否檢查過日誌?可能是有理由讓他們)以及令人討厭的回复
  3. 你在有用的時間內沒有得到你的問題的答案,有時如果你在7天之內得到答案,你應該考慮你的自我幸運,即使在這裡

我一直希望有人能夠自己開始實施JDO規範,可能他們會提供更多的東西,希望更多地關注社區,而不是總是為支持獲得報酬而煩惱,並不是說Datanucleus作者只關心商業支持,但我只是說。

我個人認為大Datanucleus作者對Datanucleus本身和社區都沒有任何義務。 他們可以在任何時候放棄整個項目,沒有人能夠判斷它,這是他們的努力和自己的財產。 但是你應該知道你在做什麼。 你看,當我們的開發人員尋找一個框架來使用時,你不能懲罰或命令框架的作者,但另一方面,你需要完成你的工作! 如果你有時間寫這個框架,為什麼你要找一個呢?!

另一方面, JDO本身有一些複雜性,如對像生命週期和東西,這不是非常直觀和通用的(我認為)。

編輯:現在我也知道JPA強制執行對像生命週期機制,所以如果您希望使用標準的ORM API(例如JPAJDO ),看起來像處理持久實體生命週期狀態是不可避免的。

我最喜歡JDO是能夠在沒有相當多努力的情況下使用任何數據庫管理系統。


我是JDO的開心用戶。 保持良好的工作人員。


都不是!

使用物化,因為更便宜(使用更少的資源),速度更快。 供參考: http://paulonjava.blogspot.mx/2010/12/tuning-google-appengine.html : http://paulonjava.blogspot.mx/2010/12/tuning-google-appengine.html

Objectify是專門為Google App Engine數據存儲設計的Java數據訪問API。 它佔據了“中間地帶”; 比JDO或JPA更易於使用和更透明,但比低級API方便得多。 Objectify旨在讓新手立即生產,同時也暴露GAE數據存儲的全部能力。

Objectify可以讓你堅持,檢索,刪除和查詢你自己的類型化對象。

@Entity
class Car {
    @Id String vin; // Can be Long, long, or String
    String color;
}

ofy().save().entity(new Car("123123", "red")).now();
Car c = ofy().load().type(Car.class).id("123123").now();
ofy().delete().entity(c);

EasyMock不支持這一點,因此你會遇到臨時接口的後備問題。

順便說一句,我聞到一點代碼wiff - 如果一個方法真的將對象視為兩個不同的東西,在這種情況下FooCloseable接口?

這對我來說意味著該方法正在執行多個操作,而我懷疑其中一個操作是“關閉” Closeable ,那麼調用代碼是否更有意義來決定是否需要'close'?

以這種方式構造代碼使得'open'和'close'保持在同一個try ... finally塊和IMHO使代碼更具可讀性,更不用說更通用的方法,並允許您傳遞僅實現Foo對象。





java google-app-engine jpa jdo