Ich möchte mein Projekt in Google App Engine mit Struts2 entwickeln. Für die Datenbank habe ich zwei Optionen: JPA und JDO. Könnt ihr mir bitte einen Vorschlag machen? Beide sind neu für mich und ich muss sie lernen. Also werde ich mich nach Ihren Antworten auf eine konzentrieren.
Vielen Dank.
Antworten:
JPA ist Suns Standard für Persistenz, JDO stirbt IMHO (eigentlich ist es tot, aber es bewegt sich immer noch). Mit anderen Worten, JPA scheint langfristig eine bessere Investition zu sein. Ich würde mich also für JPA entscheiden, wenn beide für mich neu wären.
Die GAE / J-Google-Gruppe hat mehrere Beiträge zu genau dieser Sache. Ich würde dort suchen und mir die Meinungen der Leute ansehen. Sie erhalten eine ganz andere Botschaft als die oben geäußerten Meinungen. Konzentrieren Sie sich auch auf die Tatsache, dass BigTable kein RDBMS ist. Verwenden Sie das richtige Werkzeug für den Job
Ich habe gerade diesen Vergleich zwischen JPA und JDO von DataNucleus selbst gesehen: - http://www.datanucleus.org/products/accessplatform_2_1/jdo_jpa_faq.html Ein Augenöffner.
Ich bin ein glücklicher Benutzer von JDO. Weiter so Jungs.
Menschen, die behaupten, JDO sei tot, sind nicht unbegründet. Folgendes habe ich in dem Buch Pro EJB 3 Java Persistence API gelesen: "Kurz danach gab Sun bekannt, dass JDO auf den Spezifikationswartungsmodus reduziert und die Java Persistence API sowohl von JDO als auch von den anderen Persistenzanbietern verwendet und als einziger unterstützt wird Standard für die Zukunft. ". Der Autor Mike Keith ist der Co-Spezifikationsleiter für EJB3. Natürlich ist er ein großer Unterstützer von JPA, aber ich bezweifle, dass er voreingenommen genug ist, um zu lügen.
Es ist richtig, dass bei Veröffentlichung des Buches die meisten großen Anbieter hinter JPA und nicht hinter JDO vereint waren, obwohl JDO über fortgeschrittenere technische Funktionen als JPA verfügt. Dies ist nicht überraschend, da große Unternehmen in der EE-Welt wie IBM / Oracle auch große RDBMS-Anbieter sind. In ihren Projekten verwenden mehr Kunden RDMBS als Nicht-RDMBS. JDO starb, bis GAE ihm einen großen Schub gab. Dies ist sinnvoll, da der GAE-Datenspeicher keine relationale Datenbank ist. Einige JPA-Funktionen funktionieren nicht mit Bigtables, z. B. Aggregationsabfragen, Join-Abfragen, viele-zu-viele-Beziehungen. Übrigens unterstützt GAE JDO 2.3, während nur JPA 1.0 unterstützt wird. Ich werde JDO empfehlen, wenn GAE Ihre Ziel-Cloud-Plattform ist.
Für die Aufzeichnung ist es Google App Engine (GAE), also spielen wir mit den Google-Regeln, nicht mit den Oracle / Sun-Regeln.
Darunter ist JPA nicht für GAE geeignet, es ist instabil und es funktioniert nicht wie erwartet. Weder Google ist bereit, dies zu unterstützen, noch das Nötigste.
Zum anderen ist JDO in GAE ziemlich stabil und von Google (teilweise) gut dokumentiert.
Google empfiehlt jedoch keine davon.
http://code.google.com/appengine/docs/java/datastore/overview.html
Low-Level-API bietet die beste Leistung, und bei GAE dreht sich alles um Leistung.
Fügen Sie beispielsweise 10 Entitäten hinzu
Python: 68 ms
JDO: 378 ms
Java Native: 30 ms
Im Rennen zwischen JDO und JPA kann ich nur den Datanucleus-Postern zustimmen.
Zuallererst und vor allem wissen die Poster von datanucleus, was sie tun. Sie entwickeln schließlich eine persistente Bibliothek und sind mit anderen Datenmodellen als dem relationalen, z. B. Big Table, vertraut. Ich bin mir sicher, dass ein Entwickler für den Ruhezustand hier wäre. Er hätte gesagt: "Alle unsere Annahmen beim Aufbau unserer Kernbibliotheken sind eng an das relationale Modell gekoppelt. Der Ruhezustand ist nicht für GAE optimiert."
Zweitens ist JPA zweifellos weit verbreitet, da es ein bisschen hilfreich ist, Teil des offiziellen Java EE-Stacks zu sein, aber das bedeutet nicht unbedingt, dass es besser ist. Tatsächlich entspricht JDO, wenn Sie darüber lesen, einer höheren Abstraktionsebene als JPA. JPA ist eng mit dem RDBMS-Datenmodell verbunden.
Vom Standpunkt der Programmierung aus ist die Verwendung der JDO-APIs eine viel bessere Option, da Sie konzeptionell viel weniger Kompromisse eingehen. Sie können theoretisch zu einem beliebigen Datenmodell wechseln, sofern der von Ihnen verwendete Anbieter die zugrunde liegende Datenbank unterstützt. (In der Praxis erreichen Sie selten ein so hohes Maß an Transparenz, da Sie Ihre Primärschlüssel für das GAE-Objekt festlegen und sich an einen bestimmten Datenbankanbieter, z. B. Google, binden.) Die Migration ist jedoch immer noch einfacher.
Drittens können Sie Hibernate, Eclipse Link und sogar Spring mit GAE verwenden. Google hat anscheinend große Anstrengungen unternommen, damit Sie die Frameworks verwenden können, auf denen Sie Ihre Anwendungen aufbauen. Die Leute erkennen jedoch, wenn sie ihre GAE-Anwendungen so erstellen, als würden sie auf RDBMS ausgeführt, dass sie langsam sind. Der Frühling auf GAE ist langsam. Sie können Google IO-Videos zu diesem Thema googeln, um festzustellen, ob es wahr ist.
Auch die Einhaltung von Standards ist eine vernünftige Sache, im Prinzip begrüße ich. Auf der anderen Seite führt JPA als Teil des Java EE-Stacks dazu, dass Benutzer manchmal ihre Vorstellung von Optionen verlieren. Wenn Sie so wollen, stellen Sie fest, dass Java Server Faces auch Teil des Java EE-Stacks ist. Und es ist eine unglaublich ordentliche Lösung für die Entwicklung von Web-GUI. Aber warum weichen Menschen, die klügeren Leute, wenn ich so sagen darf, letztendlich von diesem Standard ab und verwenden stattdessen GWT?
Bei alledem muss ich sagen, dass es für JPA eine sehr wichtige Sache gibt. Das ist Guice und seine bequeme Unterstützung für JPA. Scheint, dass Google in diesem Punkt nicht so schlau wie gewöhnlich war und zufrieden ist, weil es JDO vorerst nicht unterstützt. Ich denke immer noch, dass sie es sich leisten können, und irgendwann wird Guice auch JDO verschlingen ... oder vielleicht auch nicht.
Was ich JDOzum Zeitpunkt des Schreibens für schrecklich halte, ist, dass der einzige Implementierungsanbieter ist Datanucleusund die Nachteile davon der mangelnde Wettbewerb sind, der zu zahlreichen Problemen führt wie:
extensionsStackOverflowIch hoffe immer, dass jemand anfängt, die JDOSpezifikation selbst zu implementieren . Vielleicht bietet er der Community dann mehr und hoffentlich mehr freie Aufmerksamkeit und Datanucleuskümmert sich nicht immer darum, für Support bezahlt zu werden, und sagt nicht, dass sich Autoren nur um kommerziellen Support kümmern , aber ich sage nur.
Ich persönlich bin der Meinung, dass DatanucleusAutoren keinerlei Verpflichtung gegenüber sich Datanucleusselbst oder ihrer Gemeinschaft haben. Sie können das gesamte Projekt jederzeit fallen lassen und niemand kann sie dafür beurteilen, es ist ihre Anstrengung und ihr eigenes Eigentum. Aber Sie sollten wissen, worauf Sie sich einlassen. Sie sehen, wenn einer von uns Entwicklern nach einem Framework sucht, das verwendet werden kann, können Sie den Autor des Frameworks nicht bestrafen oder befehlen, aber andererseits müssen Sie Ihre Arbeit erledigen! Wenn Sie Zeit hätten, dieses Framework zu schreiben, warum würden Sie überhaupt nach einem suchen?!
Auf der anderen Seite JDOhat es einige Komplikationen wie den Lebenszyklus von Objekten und Dinge, die nicht sehr intuitiv und häufig sind (glaube ich).
Bearbeiten: Jetzt weiß ich, dass auch JPAder Objektlebenszyklusmechanismus erzwungen wird. Es scheint also unvermeidlich, sich mit Lebenszykluszuständen persistierter Entitäten zu befassen, wenn Sie eine Standard-ORM-API verwenden möchten (dh JPAoder JDO).
Was mir am besten gefällt, JDOist die Möglichkeit, ohne großen Aufwand mit JEDEM Datenbankverwaltungssystem zu arbeiten.
GAE / J wird voraussichtlich vor Jahresende MYSQL hinzufügen.
JPA ist der richtige Weg, da es als standardisierte API vorangetrieben zu werden scheint und kürzlich in EJB3.0 an Dynamik gewonnen hat. JDO scheint den Dampf verloren zu haben.
Weder!
Verwenden Sie Objectify, weil es billiger ist (weniger Ressourcen verbraucht) und schneller ist. Zu Ihrer Information: http://paulonjava.blogspot.mx/2010/12/tuning-google-appengine.html
Objectify ist eine Java-Datenzugriffs-API, die speziell für den Google App Engine-Datenspeicher entwickelt wurde. Es nimmt einen "Mittelweg" ein; einfacher zu verwenden und transparenter als JDO oder JPA, aber wesentlich bequemer als die Low-Level-API. Objectify wurde entwickelt, um Anfänger sofort produktiv zu machen und gleichzeitig die volle Leistung des GAE-Datenspeichers zu nutzen.
Mit Objectify können Sie Ihre eigenen typisierten Objekte beibehalten, abrufen, löschen und 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);