Hibernate vs JPA vs JDO - Vor-und Nachteile der einzelnen? [geschlossen]

Question

Ich bin mit ORM als Konzept vertraut, und ich habe sogar gebrauchte nHibernate vor einigen Jahren für ein .NET-Projekt; aber ich habe nicht mit dem Thema ORM in Java und hatte noch keine Chance zu nutzen jedes dieser Werkzeuge.

gehalten

Aber jetzt kann ich die Chance haben, beginnen für einen unserer Anwendungen einige ORM-Tools zu verwenden, in einem Versuch, aus einer Reihe von Legacy-Web-Services zu entfernen.

Ich habe eine harte Zeit, die die Differenz betweeen die JPA-Spezifikation zu sagen, was Sie mit der Hibernate-Bibliothek erhalten selbst, und was JDO zu bieten hat.

Also, ich verstehe, dass diese Frage ein wenig mit offenem Ende ist, aber ich hatte gehofft, einige Meinungen zu bekommen auf:

• Was sind die Vor- und Nachteile der einzelnen?
• Welche würden Sie für ein neues Projekt vorschlagen?
• Gibt es bestimmte Bedingungen, wenn es würde Sinn einen Rahmen vs anderen nutzen machen?

Answer 1

Einige Hinweise:

• JDO und JPA sind beide Spezifikationen, nicht-Implementierungen.
• Die Idee ist, dass Sie JPA-Implementierungen tauschen können, wenn Sie Ihren Code beschränken nur Standard JPA zu verwenden. (Das Gleiche gilt für JDO).
• Ruhezustand kann als eine solche Implementierung von JPA verwendet werden.
• bietet jedoch Hibernate eine native API, mit Funktionen weit über die des JPA.

IMO, ich würde Hibernate empfehlen.

---

Es gibt einige Kommentare gewesen / Fragen über das, was Sie tun sollen, wenn Sie Notwendigkeit Hibernate-spezifische Funktionen verwenden. Es gibt viele Möglichkeiten, dies zu betrachten, aber mein Rat wäre:

• Wenn Sie nicht durch die Aussicht auf Lieferantenbindung in besorgt sind, dann Ihre Wahl zwischen Hibernate machen und andere JPA und JDO-Implementierungen mit den verschiedenen herstellerspezifischen Erweiterungen in Ihrer Entscheidungsfindung .

• Wenn Sie die Aussicht auf Lieferantenbindung in besorgt sind, und Sie können JPA nicht verwenden, ohne Rückgriff spezifische Erweiterungen Hersteller, dann nicht JPA verwenden. (Das Gleiche gilt für JDO).

In der Realität müssen Sie wahrscheinlich den Handel-off wie viel Sie durch Anbieter tie-in besorgt sind im Vergleich zu wie viel Sie müssen diese herstellerspezifische Erweiterungen.

Und es gibt auch andere Faktoren, wie, wie gut Sie / Ihre Mitarbeiter die jeweiligen Technologien wissen, wie viel die Produkte in Lizenzkosten, und deren Geschichte, die Sie glauben zu wissen, was in der Zukunft für JDO und JPA passieren wird.

Answer 2

Stellen Sie sicher, dass Sie die Datanucleus Implementierung von JDO bewerten. Wir begannen mit Hibernate, weil es schien, so populär zu sein, aber ziemlich bald klar, dass es keine 100% transparent Persistenz Lösung ist. Es gibt zu viele Einschränkungen und die Dokumentation ist voll ‚wenn Sie diese Situation haben, dann müssen Sie Ihren Code wie diesen schreiben‘, die den Spaß frei Modellierung wegnahm und Codierung aber wir wollen. JDO hat nie hat mich meinen Code oder mein Modell anzupassen ist es richtig Arbeit "zu bekommen. Ich kann nur das Design und Code einfach POJOs, als ob ich sie ‚im Speicher‘ verwenden, würde nur, aber ich kann sie transparent bestehen bleiben.

Der andere Vorteil von JDO / Datanucleus über Hibernate ist, dass es nicht Reflexion ganze Laufzeit-Overhead hat und mehr Speicher effizient ist, weil es Zeit Byte-Code-Erweiterung verwendet bauen (vielleicht 1 s bis Buildzeit hinzufügen für eine große Projekt) und nicht angetriebene Proxy-Muster Laufzeit des Nachdenkens Hibernate.

Eine andere Sache, die Sie ärgerlich mit Hibernate finden könnte, ist, dass ein Verweis Sie haben, was Sie denken, das Objekt ist ... es ist oft ein ‚Proxy‘ für das Objekt. Ohne den Vorteil der Verbesserung Bytecode das Proxy-Muster ist erforderlich, auf Anfrage Laden zu ermöglichen (das heißt vermeiden in Ihrem gesamten Objektgraphen ziehen, wenn Sie in einem Top-Level-Objekt ziehen). Seien Sie bereit, equals und hashcode außer Kraft zu setzen, da das Objekt, das Sie denken, dass Sie verweisen oft ist nur ein Proxy für das Objekt.

Hier ist ein Beispiel von Frustrationen, die Sie mit Hibernate bekommen, dass Sie nicht mit JDO bekommen:

http: //blog.andrewbeacock .com / 2008/08 / wie implementierende-hibernate-safe-equals.html
http://burtbeckwith.com/blog/?p=53

Wenn Sie Codierung zu ‚Workarounds‘ dann sicher ist Hibernate für Sie. Wenn Sie sauber, rein, objektorientierte, modellgetriebene Entwicklung zu schätzen wissen, wo Sie Ihre Zeit auf der Modellierung, Design und Codierung und nichts davon auf hässliche Abhilfen verbringen dann verbringen Sie ein paar Stunden Auswertung JDO / Datanucleus . Die Stunden investiert werden tausendfach zurückgezahlt werden.

Update Februar 2017

Seit einiger Zeit nun Datanucleus implementiert die JPA Persistenz Standard neben der Persistenz JDO-Standard so die Portierung bestehender JPA Projekte aus dem Ruhezustand zu Datanucleus sollte sehr einfach sein, und Sie können mit sehr alle oben genannten Vorteile von Datanucleus erhalten wenig Code ändern, falls vorhanden. So in Bezug auf die Frage, die Wahl eines bestimmten Standard, JPA (RDBMS nur) vs JDO (RDBMS + No SQL + ODBMSes + andere) unterstützt Datanucleus beide ist Hibernate JPA nur eingeschränkt.

Performance von Hibernate DB-Updates

Ein andere Frage zu prüfen, wenn ein ORM Wahl die Effizienz seines schmutzigen Prüfmechanismus ist - das wird sehr wichtig, wenn es benötigt die SQL zu konstruieren, um die Objekte zu aktualisieren, die in der aktuellen Transaktion geändert haben - vor allem, wenn es eine Menge von Objekte. Es gibt eine detaillierte technische Beschreibung des schmutzigen Prüfmechanismus des Hibernate in dieser SO beantworten: JPA mit Hibernate einfügen sehr langsam

Answer 3

Ich habe vor kurzem ausgewertet und nahm eine Persistenz-Framework für Java-Projekt und meine Ergebnisse sind wie folgt:

Was ich sehe ist, dass die Unterstützung für JDO ist in erster Linie:

• Sie verwenden können Nicht-SQL-Datenquellen, db4o, hbase, LDAP-, BigTable, couchdb (Plugins für cassandra) etc.
• Sie können einfach wechseln aus einem SQL-Nicht-SQL-Datenquelle und umgekehrt.
• keine Proxy-Objekte und damit weniger Schmerzen in Bezug auf hashcode () und equals () Implementierungen
• mehr POJO und damit weniger Abhilfen erforderlich
• unterstützt mehr Beziehung und Feldtypen

und die Unterstützung für JPA ist in erster Linie:

• populäreren
• jdo ist tot
• doesnt Verwendung Bytecode-Erweiterung

Ich bin viel pro-PPV Beiträge der JPA-Entwickler sehen, die eindeutig nicht JDO / Datanucleus bietet schwache Argumente für nicht mit JDO verwendet haben.

Ich bin auch eine Menge Beiträge von JDO Benutzer sehen, wer zu JDO gewandert und sind viel glücklicher als Ergebnis.

In Bezug auf JPA populärer zu sein, scheint es, dass dies teilweise aufgrund ist aufgrund RDBMS Vendor-Support, anstatt es technisch überlegen zu sein. (Klingt wie VHS / Betamax mir).

JDO und es ist klar Referenzimplementierung Datanucleus ist nicht tot, wie durch Googles Annahme es für GAE und aktive Entwicklung auf dem Source-Code (http://sourceforge.net/projects/datanucleus/) gezeigt.

Ich habe eine Reihe von Beschwerden über JDO aufgrund Bytecode Verbesserung gesehen, aber keine Erklärung noch dafür, warum es schlecht ist.

In der Tat, in einer Welt, die von NoSQL-Lösungen, JDO besessen mehr und mehr immer (und der Datanucleus-Implementierung) scheint eine viel sicherere Wette.

Ich habe gerade mit JDO / Datanucleus gestartet und habe es so eingerichtet, dass ich leicht zwischen der Verwendung von db4o und mysql wechseln. Es ist hilfreich für die schnelle Entwicklung db4o zu verwenden und nicht zu viel über das DB-Schema zu kümmern und dann, sobald das Schema eine Datenbank bereitstellen stabilisiert wird. Ich auch zuversichtlich, dass später, konnte ich alle / Teil meiner Anwendung auf GAE bereitstellen oder nutzen Sie verteilten Speicher nehmen / map-reduce a la hbase / Hadoop / Cassandra, ohne zu viel Refactoring.

Ich fand die erste Hürde des mit Datanucleus ein wenig schwierig Einstieg - Die Dokumentation auf der Webseite Datanucleus ist ein wenig schwer zu bekommen in - die Tutorials sind nicht so leicht zu folgen, wie ich gerne hätte. Having said that, die ausführlichere Dokumentation über die API und Mapping ist sehr gut, wenn Sie über die anfängliche Lernkurve erhalten.

Die Antwort ist, es hängt davon ab, was Sie wollen. Ich würde eher sauberen Code, keine Vendor-Lock-in, mehr pojo orientiert, nosql Optionen Verse mehr beliebt.

Wenn Sie das warme pingelig Gefühl wollen, dass Sie die gleiche wie die meisten anderen Entwickler / Schafe tun, wählen Sie JPA / Hibernate. Wenn Sie in Ihrem Feld führen wollen, Testfahrt JDO / Datanucleus und Ihre eigene Meinung machen.

Answer 4

  

Was würden Sie vorschlagen, für ein neues Projekt?

Ich würde weder vorschlagen! Verwenden Frühling DAOs JdbcTemplate zusammen mit StoredProcedure, RowMapper und RowCallbackHandler statt.

Meine persönliche Erfahrung mit Hibernate ist, dass die eingesparte Zeit up-front mehr als durch die endlosen Tage versetzt ist, dass Sie die Zeile ausgeben unten wird versuchen Updateverhalten zu verstehen und zu debuggen Probleme wie unerwartete Kaskadierung.

Wenn Sie eine relationale DB dann je näher Ihr Code, um es verwenden, desto mehr Kontrolle Sie haben. Spring DAO Schicht ermöglicht eine Feinsteuerung der Abbildungsebene, während die Beseitigung der Notwendigkeit für Standardcode. Außerdem integriert sie in die Schicht Spring Transaktion, was bedeutet, können Sie sehr leicht hinzufügen (über AOP) komplizierte Transaktionsverhalten, ohne dass dies in Ihren Code eindringende (natürlich, erhalten Sie diese mit Hibernate auch).

Answer 5

  

JDO ist tot

JDO ist nicht tot tatsächlich so bitte Ihre Fakten überprüfen. JDO 2.2 wurde im Oktober 2008 veröffentlicht JDO 2.3 ist in der Entwicklung.

Dies ist offen, unter Apache entwickelt. Weitere Veröffentlichungen als PPV hatte, und ihre ORM-Spezifikation ist noch im Vorfeld auch die JPA2 vorgeschlagenen Merkmale

Answer 6

JDO ist mit erweiterten Funktionen als JPA finden Sie unter http://db.apache.org/jdo/ jdo_v_jpa.html

Answer 7

Ich bin mit JPA (OpenJPA Implementierung von Apache, die auf der Kodo JDO Codebasis basieren, die 5 Jahre alt und extrem schnell / zuverlässig ist). IMHO jemand, der Ihnen sagt, die Spezifikationen zu umgehen ist, Sie schlechte Beratung. Ich habe die Zeit in und war auf jeden Fall belohnt. Entweder mit JDO oder JPA können Sie Anbieter wechseln mit minimalen Änderungen (JPA hat ORM-Mapping, so dass wir weniger als einen Tag sprechen Anbieter möglicherweise ändern). Wenn Sie mehr als 100 Tabellen haben, wie ich dies tun, ist sehr groß. Plus erhalten Sie built0in Caching mit Cluster-weise Cache Vertreibungen und es ist alles gut. SQL / Jdbc ist für Hochleistungs-Abfragen in Ordnung, aber transparente Persistenz weit überlegen ist für Algorithmen und Dateneingaberoutinen zu schreiben. Ich habe nur etwa 16 SQL-Abfragen in meinem System (50k + Codezeilen).

Answer 8

Wer sagt, dass JDO tot ist, ist ein Astroturfing FUD Monger und sie wissen es.

JDO ist lebendig und gut. Die Spezifikation ist noch stärker, reife und fortgeschritten als die viel jünger und eingeschränkte JPA.

Wenn Sie sich nur begrenzen wollen, was in dem JPA-Standard zur Verfügung steht können Sie auf JPA schreiben und verwenden Datanucleus als hohe Leistung, transparente Persistenz Umsetzung als die anderen Implementierungen von PPV. Natürlich Datanucleus auch die JDO-Standard implementiert, wenn Sie die Flexibilität und Effizienz der Modellierung wollen, die JDO bringt.

Answer 9

Ich habe mich in diese suchen und kann nicht einen starken Unterschied zwischen den beiden finden. Ich denke, die große Auswahl, in der Implementierung Sie verwenden. Für mich Ich habe unter Berücksichtigung der Datanucleus Plattform, da es ein Datenspeicher Agnostiker Implementierung von beiden ist.

Answer 10

Ich habe Hibernate (JPA-Implementierung) und JPOX (JDO-Implementierung) im gleichen Projekt verwendet. JPOX arbeitete ok, aber lief ziemlich schnell in Fehler, dort, wo einige Java 5 Sprache bietet es nicht an der Zeit unterstützt hat. Es hatte Probleme schön spielen mit XA-Transaktionen. Ich war die Erzeugung der Datenbankschema aus den JDO-Objekte. Sie wollte zu einer Datenbank jedes Mal verbinden, das, wenn die Oracle-Verbindung nicht funktionieren geschieht ärgerlich ist.

Wir wechselten dann auf Ruhezustand. Wir toyed um mit nur mit reiner JPA für eine Weile, aber wir brauchten einige der Hibernate spezifischen Merkmale zu verwenden, um die Zuordnung zu tun. Das Ausführen des gleichen Code auf mehreren Datenbanken ist sehr einfach. Hibernate scheint manchmal Objekte aggressiv oder haben seltsames Caching-Verhalten cachen. Es gibt ein paar DDL-Konstrukte Hibernate nicht verarbeiten kann und so werden sie in einer zusätzlichen Datei definiert, um die Datenbank zu initialisieren ausgeführt wird. Wenn ich in ein Hibernate Problem ausgeführt haben gibt es oft viele Menschen, die in das gleiche Problem ausgeführt haben, die leichter für Lösungen googeln macht. Schließlich scheint Hibernate gut gestaltet und zuverlässig sein.

haben einige andere Responder gerade vorgeschlagen SQL. Der eigentliche Killer Anwendungsfall für objektrelationale Mapping ist Prüfung und Entwicklung. Die Datenbanken, die gebaut werden, um große Datenmengen zu verarbeiten sind in der Regel teuer und oder sie sind schwierig zu installieren. Sie sind schwer zu testen mit. Es gibt viele In-Memory-Java-Datenbanken, die verwendet werden können, mit zu testen, aber ist in der Regel nutzlos für die Produktion. Die Möglichkeit, eine echte, aber begrenzte Datenbank zu verwenden, wird die Entwicklung der Produktivität und Codesicherheit erhöhen.

Answer 11

ich eine Probe WebApp gemacht Mai 2012, die JDO verwendet 3.0 & Datanucleus 3.0 - sehen, wie sauber es ist: https://github.com/TorbenVesterager/BadAssWebApp

Okay, vielleicht ist es ein wenig zu sauber, weil ich die POJOs sowohl für die Datenbank und das JSON-Client, aber es macht Spaß:)

PS: Enthält ein paar SuppressWarnings Anmerkungen (entwickelt in IntelliJ 11)