JDO vs JPA für Java auf Google App Engine

StackOverflow https://stackoverflow.com/questions/1418219

Frage

Ich möchte mein Projekt auf Google App Engine mit Struts2 entwickeln. Für die Datenbank habe ich zwei Optionen JPA und JDO. Werdet ihr mir bitte auf sie vorschlagen? Beide sind neu für mich und ich brauche sie zu lernen. Also werde ich auf einem nach Ihren Antworten fokussiert werden.

Danke.

War es hilfreich?

Lösung

JPA ist Standard Sun für Persistenz, JDO IMHO stirbt (tatsächlich, es ist tot, aber immer noch in Bewegung). Mit anderen Worten, scheint JPA eine bessere Investition auf lange Sicht zu sein. Also ich denke, ich würde JPA wählen, ob beide neu für mich waren.

Andere Tipps

Die GAE / J Google-Gruppe hat mehrere Beiträge über diese sehr Sache. Ich würde dort eine Suche und die Meinung der Menschen sehen. Sie werden eine ganz andere Botschaft an den Meinungen oben zum Ausdruck kommen. Auch konzentrieren sich auf die Tatsache, dass BigTable ist kein RDBMS. Verwenden Sie das richtige Werkzeug für den Job

Gerade gesehen, diesen Vergleich zwischen PPV und JDO von Datanucleus sich: - http://www.datanucleus.org/products/accessplatform_2_1/jdo_jpa_faq.html Ein Augenöffner.

Ich bin ein glücklicher Benutzer von JDO. Halten Sie die gute Arbeit, Jungs.

Die Leute behaupten, JDO tot ist, ist nicht ohne Verdienst. Hier ist, was ich in dem Buch Pro EJB 3 Java Persistence API zu lesen: „Kurz danach Sun angekündigt, dass JDO Spezifikation Wartungsmodus reduziert werden würde und dass die Java Persistence API von beiden JDO und die anderen Persistenz-Anbieter ziehen würde und sich die einzelnen unterstützten geht nach vorn Standard. ". Der Autor Mike Keith ist der Co-Spezifikation Führer auf EJB3. Natürlich ist er ein großer Fan von PPV, aber ich bezweifle, dass er genug vorgespannt ist, liegen.

Es ist wahr, dass, wenn das Buch veröffentlicht wurde, die meisten großen Anbieter hinter JPA vereint waren, anstatt JDO, obwohl JDO fortgeschritteneren technische Eigenschaften als JPA hat. Es ist nicht verwunderlich, weil große Spieler in der EE Welt wie IBM / Oracle auch große RDBMS-Anbieter sind. Weitere Kunden nutzen RDMBS als nicht-RDMBS in ihren Projekten. JDO im Sterben liegt, bis GAE es einen großen Schub gab. Es macht Sinn, weil GAE-Datenspeicher nicht relationale Datenbank ist. Einige JPA Funktionen funktionieren nicht mit BigTable wie Aggregationsanfragen, Join-Abfragen, many-to-many-Beziehungen gehört. BTW, unterstützt GAE 2.3 JDO während nur JPA 1.0 unterstützen. Ich werde empfehlen JDO wenn GAE Ihr Ziel Cloud-Plattform ist.

Für das Protokoll, es ist Google App Engine (GAE), so dass wir spielen mit der Google-Regeln nicht mit den Oracle / Sun-Regeln.

Unter es ist JPA für GAE nicht geeignet, es ist instabil und es funktioniert nicht wie erwartet. Weder Google ist bereit, sie zu unterstützen, aber das Nötigste.

Und andererseits JDO ist recht stabil in GAE und es ist (in einem gewissen Ausmaß) auch durch Google dokumentiert.

Allerdings ist Google nicht von ihnen empfehlen.

http://code.google.com/appengine/docs/ java / Datenspeicher / overview.html

Low-Level-API gibt die beste Leistung und GAE dreht sich alles um Leistung.

http://gaejava.appspot.com/

Zum Beispiel werden 10 Unternehmen

  

Python: 68ms

     

JDO: 378ms

     

Java Native: 30ms

Im Rennen zwischen JDO vs JPA kann ich nur mit dem Datanucleus Poster zustimmen.

Zu allererst und auch am wichtigsten ist, wissen die Plakate von Datanucleus, was sie tun. Sie sind schließlich eine persistente Bibliothek entwickelt und sind vertraut mit Datenmodellen anderer als der relationalen, z.B. Großer Tisch. Ich bin sicher, dass id ein Entwickler für Hibernate hier wäre, würde er sagen: „Alle unsere Annahmen als unsere Kernbibliotheken Aufbau sind relationale Modell eng gekoppelt, Hibernate nicht für GAE optimiert ist“

Zweitens JPA ist fraglos in mehr weit verbreiteten Einsatz, ein Teil des offiziellen Java EE-Stack zu sein hilft ein wenig, aber das bedeutet nicht zwangsläufig, dass es besser ist. In der Tat, JDO, wenn man darüber lesen, entspricht eine höhere Abstraktionsebene als PPV. JPA ist fest mit dem RDBMS Datenmodell gekoppelt.

Von einem Programmierstandpunkt ist die JDO-APIs eine viel bessere Option, da Sie konzeptionell viel weniger sind zu beeinträchtigen. Sie können wechseln, theoretisch zu jedem Datenmodell von Ihrem Wunsch, sofern der Erbringer Sie die zugrunde liegende Datenbank verwenden unterstützt. (In der Praxis erreichen Sie selten einen so hohen Grad an Transparenz, da finden Sie sich Ihre Primärschlüssel auf GAE Objekt einstellen und Sie werden sie zu einem bestimmten Datenbank-Anbietern werden zu binden, zum Beispiel Google). wird es noch einfacher sein, obwohl zu migrieren.

Drittens können Sie mit Hibernate, Eclipse-Link und sogar mit GAE Frühling. Google scheint eine große Anstrengung gemacht zu haben, damit Sie den Frameworks verwenden Sie Ihre Anwendungen für den Aufbau auf verwendet werden. Aber was die Menschen erkennen, wenn sie ihre GAE-Anwendungen zu erstellen, als ob sie auf RDBMS ausgeführt wurden, ist, dass sie langsam sind. Frühling auf GAE ist langsam. Sie können zu diesem Thema Google IO Videos google zu sehen, dass es wahr ist.

Auch Einhaltung von Standards ist eine gute vernünftige Sache zu tun, grundsätzlich begrüße ich. Auf der anderen Seite, JPA Teil des Stapels Java EE zu sein macht die Menschen, zu Zeiten, ihre Vorstellung von Optionen verlieren. Erkennen, wenn man will, dass Java Server Faces ist auch der Java EE Stapelteil. Und es ist eine unglaublich saubere Lösung für Web-GUI-Entwicklung. Aber am Ende, warum Menschen tun, die intelligentere Menschen, wenn ich so sagen darf, von dieser Norm abweichen und verwenden GWT statt?

Bei alldem muss ich übersättigen, dass es eine sehr wichtige Sache für JPA gehen ist. Das ist Guice und seine günstige Unterstützung für JPA. Es scheint, dass Google in diesem Punkt nicht so schlau wie üblich und ist zufrieden, denn jetzt in nicht JDO unterstützt. Ich denke immer noch, dass sie es sich leisten können, und schließlich Guice wird JDO verschlingen auch, ... oder vielleicht auch nicht.

Go JDO. Auch wenn Sie in sie haben keine Erfahrung, es ist nicht schwer zu holen, und Sie werden eine neue Fertigkeit unter dem Gürtel haben!

Was ich denke, ist schrecklich über die Verwendung von JDO zum Zeitpunkt der Abfassung dieses ist, dass die einzige Implementierung Anbieter ist Datanucleus und die Nachteile, dass der Mangel an Wettbewerb, der zu zahlreichen Fragen führt wie:

  1. Eine nicht sehr ausführliche Dokumentation über einige Aspekte wie extensions
  2. Sie in der Regel sarkastische Antworten von den Autoren erhalten wie (Haben Sie die Protokolle überprüft? Sein kann es einen Grund gibt sie dafür, dass) und lästige Reaktionen wie die
  3. Sie haben keine Antwort auf Ihre Frage in einer hilfreichen Menge an Zeit, manchmal, wenn Sie eine Antwort in weniger als 7 Tagen erhalten, sollten Sie sich selbst glücklich, auch hier auf StackOverflow
    4. prüfen

Ich hoffe immer für jemand die JDO Spezifikation zu beginnen, sich die Umsetzung wird dann werden sie etwas mehr und hoffentlich mehr kostenlos die Aufmerksamkeit auf die Gemeinschaft bieten und nicht immer darum zu kümmern, bezahlt werden Unterstützung, damit nicht sagen, dass Datanucleus Autoren nur über kommerzielle Unterstützung kümmern, aber ich bin einfach nur sagen.

Ich halte persönlich Datanucleus Autoren hat keinerlei Verpflichtung, sich zu Datanucleus noch es ist Gemeinschaft. Sie können das gesamte Projekt jederzeit fallen und niemand kann sie für sie beurteilen, es ist ihre Mühe und ihr Eigentum. Aber Sie sollten wissen, was Sie sich einlassen. Sie sehen, wenn einer von uns Entwickler für einen Rahmen aussehen zu verwenden, können Sie den Rahmen des Autors nicht bestrafen oder befehlen, aber auf der anderen Seite, müssen Sie Ihre Arbeit getan! Wenn Sie Zeit diesen Rahmen zu schreiben hatte, warum sollte man in erster Linie sucht ein?

Auf der anderen Seite, selbst JDO hat einige Komplikationen wie Objekte Lebenszyklus und Sachen, die nicht sehr intuitiv und üblich ist (glaube ich).

Edit: Jetzt weiß ich auch erzwingt JPA den Objektlebenszyklus-Mechanismus, so sieht es aus wie sein unvermeidlich mit persistenten Entitäten Lebenszyklus Zustände zu behandeln, wenn Sie einen Standard ORM API (das heißt JPA oder JDO)

verwenden möchten

Was ich am meisten an JDO mag, ist die Fähigkeit, mit jedem Datenbank-Management-System ohne großen Aufwand zu arbeiten.

GAE / J ist geplant, MYSQL vor dem Ende des Jahres hinzuzufügen.

JPA ist der Weg zu gehen, wie es als standardisiertes API geschoben zu werden scheint und Dynamik in EJB3.0 vor kurzem erhalten hat .. JDO scheint den Dampf verloren zu haben.

Weder!

Verwenden Objectify, weil billiger ist (mit weniger Ressourcen) und ist schneller. Zur Info: http://paulonjava.blogspot.mx/2010/12/tuning -Google-appengine.html

  

Objectify ist ein Zugang Java-Daten-API speziell entwickelt für die   Google App Engine-Datenspeicher. Es befindet sich in einem „Mittelweg“; einfacher zu   verwenden und transparenter als JDO oder JPA, aber deutlich mehr   bequemer als der Low-Level-API. Objectify ist so konzipiert, machen   Neulinge sofort produktiv aber auch die volle Leistung des Exposes   GAE Datenspeicher.

Objectify können Sie anhalten, abrufen, löschen und Ihre eigene typisierte Objekte abfragen. 

@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);
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top