Hibernate vs JPA vs JDO - Vor- und Nachteile von jedem? [geschlossen]

Ich bin mit ORM als Konzept vertraut und habe nHibernate vor einigen Jahren sogar für ein .NET-Projekt verwendet. Ich habe mich jedoch nicht mit dem Thema ORM in Java beschäftigt und hatte keine Gelegenheit, eines dieser Tools zu verwenden.

Aber jetzt habe ich möglicherweise die Möglichkeit, einige ORM-Tools für eine unserer Anwendungen zu verwenden, um mich von einer Reihe älterer Webdienste zu entfernen.

Es fällt mir schwer, den Unterschied zwischen der JPA-Spezifikation, dem, was Sie mit der Hibernate-Bibliothek selbst erhalten, und dem, was JDO zu bieten hat, zu erkennen.

Ich verstehe also, dass diese Frage etwas offen ist, aber ich hatte gehofft, einige Meinungen zu bekommen über:

• Was sind die Vor- und Nachteile von jedem?
• Welches würden Sie für ein neues Projekt vorschlagen?
• Gibt es bestimmte Bedingungen, unter denen es sinnvoll wäre, ein Framework gegen das andere zu verwenden?

Einige Notizen:

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

IMO würde ich Hibernate empfehlen.

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

• Wenn Sie sich keine Sorgen über die Aussicht auf eine Lieferantenbindung machen, treffen Sie Ihre Wahl zwischen Hibernate und anderen JPA- und JDO-Implementierungen, einschließlich der verschiedenen herstellerspezifischen Erweiterungen bei Ihrer Entscheidungsfindung.

• Wenn Sie sich Sorgen über die Aussicht auf eine Lieferantenbindung machen und JPA nicht verwenden können, ohne auf herstellerspezifische Erweiterungen zurückzugreifen, verwenden Sie JPA nicht. (Das Gleiche gilt für JDO).

In der Realität müssen Sie wahrscheinlich abwägen, wie sehr Sie sich über die Lieferantenbindung Sorgen machen und wie sehr Sie diese herstellerspezifischen Erweiterungen benötigen.

Und es gibt noch andere Faktoren, wie zum Beispiel, wie gut Sie / Ihre Mitarbeiter die jeweiligen Technologien kennen, wie viel die Produkte bei der Lizenzierung kosten und wessen Geschichte Sie glauben, was in Zukunft für JDO und JPA passieren wird.

Stellen Sie sicher, dass Sie die DataNucleus-Implementierung von JDO evaluieren. Wir haben mit Hibernate angefangen, weil es so beliebt zu sein schien, aber ziemlich bald wurde uns klar, dass es sich nicht um eine 100% transparente Persistenzlösung handelt. Es gibt zu viele Vorbehalte und die Dokumentation ist voll von "Wenn Sie diese Situation haben, müssen Sie Ihren Code so schreiben", die den Spaß am freien Modellieren und Codieren nach Belieben genommen hat. JDO hat mich nie veranlasst, meinen Code oder mein Modell anzupassen, damit es ordnungsgemäß funktioniert. Ich kann einfache POJOs einfach so entwerfen und codieren, als würde ich sie nur "im Speicher" verwenden, aber ich kann sie transparent beibehalten.

Der andere Vorteil von JDO / DataNucleus gegenüber dem Ruhezustand besteht darin, dass es nicht den gesamten Aufwand für die Laufzeitreflexion hat und speichereffizienter ist, da die Verbesserung des Build-Time-Byte-Codes verwendet wird (möglicherweise wird Ihre Build-Zeit für ein großes Projekt um 1 Sekunde verlängert) als das zur Laufzeitreflexion angetriebene Proxy-Muster des Ruhezustands.

Eine andere Sache, die Sie im Ruhezustand möglicherweise stören, ist, dass ein Verweis auf das, was Sie denken, das Objekt ist ... es ist oft ein "Proxy" für das Objekt. Ohne den Vorteil der Bytecode-Verbesserung ist das Proxy-Muster erforderlich, um das Laden bei Bedarf zu ermöglichen (dh vermeiden Sie das Ziehen Ihres gesamten Objektdiagramms, wenn Sie ein Objekt der obersten Ebene ziehen). Seien Sie darauf vorbereitet, Gleichheits- und Hashcode zu überschreiben, da das Objekt, auf das Sie sich beziehen, häufig nur ein Proxy für dieses Objekt ist.

Hier ist ein Beispiel für Frustrationen, die Sie mit Hibernate bekommen, die Sie mit JDO nicht bekommen werden:

http://blog.andrewbeacock.com/2008/08/how-to-implement-hibernate-safe-equals.html
http://burtbeckwith.com/blog/?p=53

Wenn Sie gerne zu Problemumgehungen codieren, ist Hibernate genau das Richtige für Sie. Wenn Sie eine saubere, reine, objektorientierte, modellgetriebene Entwicklung schätzen, bei der Sie Ihre ganze Zeit mit Modellieren, Entwerfen und Codieren verbringen und nichts davon mit hässlichen Problemumgehungen, dann verbringen Sie einige Stunden mit der Evaluierung von JDO / DataNucleus . Die investierten Stunden werden tausendfach zurückgezahlt.

Update Februar 2017

Seit geraumer Zeit implementiert DataNucleus zusätzlich zum JDO-Persistenzstandard den JPA-Persistenzstandard. Daher sollte die Portierung vorhandener JPA-Projekte von Hibernate nach DataNucleus sehr einfach sein und Sie können alle oben genannten Vorteile von DataNucleus mit sehr geringen Codeänderungen nutzen , wenn überhaupt. In Bezug auf die Frage, die Auswahl eines bestimmten Standards, JPA (nur RDBMS) gegenüber JDO (RDBMS + kein SQL + ODBMS + andere), unterstützt DataNucleus beide, Hibernate ist nur auf JPA beschränkt.

Leistung von Hibernate DB-Updates

Ein weiteres Problem, das bei der Auswahl eines ORM berücksichtigt werden muss, ist die Effizienz seines Dirty-Checking-Mechanismus. Dies ist sehr wichtig, wenn SQL erstellt werden muss, um die Objekte zu aktualisieren, die sich in der aktuellen Transaktion geändert haben - insbesondere, wenn viele Objekte vorhanden sind. In dieser SO-Antwort finden Sie eine detaillierte technische Beschreibung des schmutzigen Überprüfungsmechanismus von Hibernate: JPA mit sehr langsamer HIBERNATE-Einfügung

Ich habe kürzlich ein Persistenz-Framework für ein Java-Projekt evaluiert und ausgewählt. Meine Ergebnisse lauten wie folgt:

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

• Sie können Nicht-SQL-Datenquellen, db4o, hbase, ldap, bigtable, couchdb (Plugins für Cassandra) usw. verwenden.
• Sie können problemlos von einer SQL- zu einer Nicht-SQL-Datenquelle und umgekehrt wechseln.
• Keine Proxy-Objekte und daher weniger Schmerzen in Bezug auf Hashcode () - und Equals () - Implementierungen
• Mehr POJO und damit weniger Problemumgehungen erforderlich
• unterstützt mehr Beziehungs- und Feldtypen

und die Unterstützung zugunsten von JPA ist in erster Linie:

• bekannter
• jdo ist tot
• verwendet keine Bytecode-Verbesserung

Ich sehe viele Pro-JPA-Posts von JPA-Entwicklern, die JDO / Datanucleus eindeutig nicht verwendet haben und schwache Argumente dafür liefern, JDO nicht zu verwenden.

Ich sehe auch viele Beiträge von JDO-Benutzern, die auf JDO migriert sind und daher viel glücklicher sind.

In Bezug auf die Popularität von JPA scheint dies teilweise auf die Unterstützung von RDBMS-Anbietern zurückzuführen zu sein, anstatt technisch überlegen zu sein. (Klingt für mich nach VHS / Betamax).

JDO und seine Referenzimplementierung Datanucleus ist eindeutig nicht tot, wie die Übernahme durch Google für GAE und die aktive Entwicklung des Quellcodes (http://sourceforge.net/projects/datanucleus/) zeigt.

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

In einer Welt, die immer mehr von NoSQL-Lösungen besessen ist, scheint JDO (und die Implementierung des Datenkerns) eine viel sicherere Wahl zu sein.

Ich habe gerade angefangen, JDO / Datanucleus zu verwenden, und habe es so eingerichtet, dass ich problemlos zwischen der Verwendung von db4o und mysql wechseln kann. Für eine schnelle Entwicklung ist es hilfreich, db4o zu verwenden und sich nicht zu viele Gedanken über das DB-Schema zu machen. Sobald das Schema stabilisiert ist, kann es in einer Datenbank bereitgestellt werden. Ich bin auch zuversichtlich, dass ich später meine gesamte / einen Teil meiner Anwendung für GAE bereitstellen oder verteilten Speicher nutzen / Karten reduzieren / a hbase / hadoop / cassandra reduzieren kann, ohne zu viel Refactoring.

Ich fand die anfängliche Hürde beim Einstieg in Datanucleus etwas schwierig - Die Dokumentation auf der Datanucleus-Website ist etwas schwierig - die Tutorials sind nicht so einfach zu befolgen, wie ich es mir gewünscht hätte. Trotzdem ist die detailliertere Dokumentation der API und des Mappings sehr gut, sobald Sie die anfängliche Lernkurve überwunden haben.

Die Antwort ist, es kommt darauf an, was Sie wollen. Ich hätte lieber saubereren Code, No-Vendor-Lock-In, Pojo-orientierter, nosql-Optionen versus populärere.

Wenn Sie das warme, pingelige Gefühl haben möchten, dass Sie das Gleiche tun wie die meisten anderen Entwickler / Schafe, wählen Sie JPA / Ruhezustand. Wenn Sie auf Ihrem Gebiet führend sein möchten, testen Sie JDO / Datanucleus und entscheiden Sie sich selbst.

Welches würden Sie für ein neues Projekt vorschlagen?

Ich würde weder vorschlagen! Verwenden Frühling DAO ist JdbcTemplatezusammen mit StoredProcedure, RowMapperund RowCallbackHandlerstattdessen.

Meine persönliche Erfahrung mit Hibernate ist, dass die im Voraus eingesparte Zeit durch die endlosen Tage, die Sie später damit verbringen werden, Probleme wie unerwartetes kaskadierendes Update-Verhalten zu verstehen und zu debuggen, mehr als ausgeglichen wird.

Wenn Sie eine relationale Datenbank verwenden, haben Sie umso mehr Kontrolle, je näher Ihr Code daran ist. Die DAO-Schicht von Spring ermöglicht die Feinsteuerung der Mapping-Schicht, ohne dass Boilerplate-Code erforderlich ist. Außerdem ist es in die Transaktionsschicht von Spring integriert, was bedeutet, dass Sie sehr einfach (über AOP) kompliziertes Transaktionsverhalten hinzufügen können, ohne dass dies in Ihren Code eindringt (natürlich erhalten Sie dies auch mit Hibernate).

JDO ist tot

JDO ist eigentlich nicht tot. Bitte überprüfen Sie Ihre Fakten. JDO 2.2 wurde im Oktober 2008 veröffentlicht. JDO 2.3 befindet sich in der Entwicklung.

Dies wird offen unter Apache entwickelt. Es gibt mehr Releases als JPA, und die ORM-Spezifikation ist noch vor den von JPA2 vorgeschlagenen Funktionen

JDO verfügt über erweiterte Funktionen als JPA (siehe http://db.apache.org/jdo/jdo_v_jpa.html)

Ich verwende JPA (OpenJPA-Implementierung von Apache, die auf der KODO JDO-Codebasis basiert, die mindestens 5 Jahre alt und extrem schnell / zuverlässig ist). IMHO gibt Ihnen jeder, der Ihnen sagt, dass Sie die Spezifikationen umgehen sollen, schlechte Ratschläge. Ich habe mir die Zeit genommen und wurde definitiv belohnt. Mit JDO oder JPA können Sie den Anbieter mit minimalen Änderungen wechseln (JPA verfügt über eine Orm-Zuordnung, sodass wir weniger als einen Tag sprechen, um möglicherweise den Anbieter zu wechseln). Wenn Sie mehr als 100 Tische haben, wie ich, ist das riesig. Außerdem erhalten Sie ein integriertes Caching mit clusterweisen Cache-Räumungen, und alles ist gut. SQL / Jdbc eignet sich gut für Hochleistungsabfragen, aber die transparente Persistenz ist beim Schreiben Ihrer Algorithmen und Dateneingaberoutinen weit überlegen. Ich habe nur ungefähr 16 SQL-Abfragen in meinem gesamten System (mehr als 50.000 Codezeilen).

Ich habe mich selbst damit befasst und kann keinen starken Unterschied zwischen den beiden feststellen. Ich denke, die große Wahl ist, welche Implementierung Sie verwenden. Für mich selbst habe ich die DataNucleus- Plattform in Betracht gezogen , da es sich um eine datenspeicherunabhängige Implementierung von beiden handelt.

Jeder, der sagt, dass JDO tot ist, ist ein Astroturfing-FUD-Händler und sie wissen es.

JDO lebt und es geht ihm gut. Die Spezifikation ist immer noch leistungsfähiger, ausgereifter und fortgeschrittener als die viel jüngere und eingeschränkte JPA.

Wenn Sie sich nur auf das beschränken möchten, was im JPA-Standard verfügbar ist, können Sie in JPA schreiben und DataNucleus als leistungsstarke, transparentere Persistenzimplementierung verwenden als die anderen Implementierungen von JPA. Natürlich implementiert DataNucleus auch den JDO-Standard, wenn Sie die Flexibilität und Effizienz der Modellierung wünschen, die JDO bietet.

Ich habe Hibernate (JPA-Implementierung) und JPOX (JDO-Implementierung) im selben Projekt verwendet. JPOX funktionierte einwandfrei, stieß jedoch ziemlich schnell auf Fehler, da einige Java 5-Sprachfunktionen zu diesem Zeitpunkt nicht unterstützt wurden. Es hatte Probleme, mit XA-Transaktionen gut zu spielen. Ich habe das Datenbankschema aus den JDO-Objekten generiert. Es wollte jedes Mal eine Verbindung zu einer Datenbank herstellen, was ärgerlich ist, wenn Ihre Oracle-Verbindung nicht funktioniert.

Wir sind dann in den Ruhezustand gewechselt. Wir haben eine Weile damit gespielt, nur reines JPA zu verwenden, aber wir mussten einige der Hibernate-spezifischen Funktionen verwenden, um das Mapping durchzuführen. Das Ausführen des gleichen Codes in mehreren Datenbanken ist sehr einfach. Der Ruhezustand scheint Objekte aggressiv zwischenzuspeichern oder hat manchmal nur ein seltsames Caching-Verhalten. Es gibt einige DDL-Konstrukte, die Hibernate nicht verarbeiten kann. Sie werden daher in einer zusätzlichen Datei definiert, die zum Initialisieren der Datenbank ausgeführt wird. Wenn ich auf ein Problem im Ruhezustand gestoßen bin, sind oft viele Menschen auf dasselbe Problem gestoßen, was das Googeln nach Lösungen erleichtert. Schließlich scheint Hibernate gut gestaltet und zuverlässig zu sein.

Einige andere Antwortende haben vorgeschlagen, nur SQL zu verwenden. Der wahre Killer-Anwendungsfall für die objektrelationale Zuordnung ist das Testen und Entwickeln. Die Datenbanken, die für die Verarbeitung großer Datenmengen erstellt wurden, sind in der Regel teuer und schwer zu installieren. Sie sind schwer zu testen. Es gibt viele speicherinterne Java-Datenbanken, mit denen getestet werden kann, die jedoch für die Produktion normalerweise unbrauchbar sind. Die Verwendung einer realen, aber begrenzten Datenbank erhöht die Entwicklungsproduktivität und die Codezuverlässigkeit.

Ich habe im Mai 2012 eine Beispiel-WebApp erstellt, die JDO 3.0 und DataNucleus 3.0 verwendet. Sehen Sie sich an, wie sauber sie ist: https://github.com/TorbenVesterager/BadAssWebApp

Okay, vielleicht ist es ein bisschen zu sauber, weil ich die POJOs sowohl für die Datenbank als auch für den JSON-Client verwende, aber es macht Spaß :)

PS: Enthält einige SuppressWarnings-Anmerkungen (entwickelt in IntelliJ 11).