Hibernate vs JPA vs JDO - pro e contro di ciascuno? [chiuso]

174

Conosco ORM come concetto e ho persino usato nHibernate diversi anni fa per un progetto .NET; tuttavia, non ho tenuto il passo con l'argomento di ORM in Java e non ho avuto la possibilità di utilizzare nessuno di questi strumenti.

Ma ora potrei avere la possibilità di iniziare a utilizzare alcuni strumenti ORM per una delle nostre applicazioni, nel tentativo di abbandonare una serie di servizi Web legacy.

Sto facendo fatica a dire la differenza tra le specifiche JPA, cosa ottieni con la libreria Hibernate stessa e cosa ha da offrire JDO.

Quindi, capisco che questa domanda è un po 'aperta, ma speravo di ottenere alcune opinioni su:

Quali sono i pro ed i contro di ognuno?
Quale consiglieresti per un nuovo progetto?
Ci sono alcune condizioni in cui avrebbe senso usare un framework rispetto all'altro?

— opaco b
fonte

112

Alcune note:

JDO e JPA sono entrambe specifiche, non implementazioni.
L'idea è che è possibile scambiare le implementazioni JPA, se si limita il codice a utilizzare solo JPA standard. (Idem per JDO.)
L'ibernazione può essere utilizzata come una di tali implementazioni dell'APP.
Tuttavia, Hibernate fornisce un'API nativa, con funzionalità superiori a quelle di JPA.

IMO, consiglierei Hibernate.

Ci sono stati alcuni commenti / domande su cosa dovresti fare se hai bisogno di usare le funzionalità specifiche di Hibernate. Esistono molti modi per esaminarlo, ma il mio consiglio sarebbe:

Se non sei preoccupato dalla prospettiva del collegamento del fornitore, fai la tua scelta tra Hibernate e altre implementazioni JPA e JDO, comprese le varie estensioni specifiche del fornitore nel processo decisionale.
Se sei preoccupato dalla prospettiva del collegamento del fornitore e non puoi utilizzare JPA senza ricorrere a estensioni specifiche del fornitore, non utilizzare JPA. (Idem per JDO).

In realtà, probabilmente dovrai compensare quanto sei preoccupato dal collegamento del fornitore rispetto a quanto hai bisogno di quelle estensioni specifiche del fornitore.

E ci sono anche altri fattori, come quanto tu / il tuo personale conoscete le rispettive tecnologie, quanto costeranno i prodotti in licenza e la cui storia credete su ciò che accadrà in futuro per JDO e JPA.

— kit di strumenti
fonte

8

toolkit, carino e breve. Un altro punto degno di nota è che JPA non impedisce di utilizzare funzionalità specifiche di implementazione, se necessario. Ciò significa che JPA consente di utilizzare qualsiasi funzionalità di Hibernate quando Hibernate è un'implementazione.

— topchef

1

Quali sarebbero i vantaggi dell'utilizzo di JPA se avessi bisogno di alcune funzionalità specifiche di Hibernate?

— Bruno Reis,

22

Una nota importante che dovrebbe essere aggiunta: mentre JPA e JDO hanno entrambi un eccellente supporto per RDBMS, JDO è indipendente dal "datastore" e quindi non si limita al mondo RDBMS. Con l'ondata di NoSQL al momento, una persona sarebbe saggia a considerare l'utilizzo di uno standard di persistenza che eviti di bloccare le proprie app nel tradizionale mondo * SQL. Le applicazioni JDO possono essere facilmente implementate datastore non RDBMS. L'elenco completo dei datastore supportati è disponibile all'indirizzo: datanucleus.org/products/accessplatform/datastores.html

— Volksman,

2

@Golfman perché scegliere in base a cosa potrebbe accadere? Non c'è nulla che ti impedisca di inserire qualcos'altro in seguito se mai avessi bisogno del supporto NoSQL ... KISS

— TM.

1

@Bruno - quando si utilizza parti non Hibernate-specifici di Hibernate, che si sta utilizzando JPA. Ovviamente, il vantaggio di limitarti al puro JPA è che puoi passare a un'altra implementazione JPA più facilmente.

— Stephen C,

69

Assicurati di valutare l'implementazione DataNucleus di JDO. Abbiamo iniziato con Hibernate perché sembrava essere così popolare ma ben presto si è reso conto che non è una soluzione di persistenza trasparente al 100%. Ci sono troppi avvertimenti e la documentazione è piena di "se hai questa situazione, allora devi scrivere il tuo codice in questo modo" che ha tolto il divertimento di modellare e codificare liberamente come vogliamo. JDO non mi ha mai indotto a modificare il mio codice o il mio modello per farlo funzionare correttamente. Posso semplicemente progettare e codificare semplici POJO come se volessi usarli solo "in memoria", ma posso perseverarli in modo trasparente.

L'altro vantaggio di JDO / DataNucleus rispetto all'ibernazione è che non ha tutto il sovraccarico di riflessione del tempo di esecuzione ed è più efficiente in termini di memoria perché utilizza il miglioramento del codice byte del tempo di costruzione (forse aggiungere 1 secondo al tempo di costruzione per un progetto di grandi dimensioni) piuttosto del modello proxy basato sulla riflessione del tempo di esecuzione di ibernazione.

Un'altra cosa che potresti trovare fastidiosa con Hibernate è che un riferimento che hai a quello che pensi sia l'oggetto ... è spesso un "proxy" per l'oggetto. Senza il vantaggio del miglioramento del codice byte, è necessario il modello proxy per consentire il caricamento su richiesta (ovvero evitare di estrarre l'intero grafico dell'oggetto quando si inserisce un oggetto di livello superiore). Preparati a sovrascrivere equals e hashcode perché l'oggetto a cui pensi di fare riferimento è spesso solo un proxy per quell'oggetto.

Ecco un esempio di frustrazioni che otterrai con Hibernate che non otterrai con JDO:

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

Se ti piace programmare "soluzioni alternative", sicuramente Hibernate fa per te. Se apprezzi lo sviluppo pulito, puro, orientato agli oggetti, guidato da modelli in cui dedichi tutto il tuo tempo alla modellazione, alla progettazione e alla codifica e nessuno di questi su soluzioni orribili, passa qualche ora a valutare JDO / DataNucleus . Le ore investite verranno rimborsate mille volte.

Aggiornamento febbraio 2017

Da un po 'di tempo ormai DataNucleus implementa lo standard di persistenza JPA oltre allo standard di persistenza JDO, quindi il porting di progetti JPA esistenti da Hibernate a DataNucleus dovrebbe essere molto semplice e puoi ottenere tutti i vantaggi di DataNucleus sopra menzionati con una modifica del codice molto ridotta , se presente. Quindi, in termini di domanda, la scelta di uno standard particolare, JPA (solo RDBMS) vs JDO (RDBMS + No SQL + ODBMSes + altri), DataNucleus supporta entrambi, Hibernate è limitato al solo JPA.

Prestazioni degli aggiornamenti di Hibernate DB

Un altro problema da considerare quando si sceglie un ORM è l'efficienza del suo meccanismo di controllo sporco - che diventa molto importante quando deve costruire l'SQL per aggiornare gli oggetti che sono cambiati nella transazione corrente - specialmente quando ci sono molti oggetti. C'è una descrizione tecnica dettagliata del meccanismo di controllo sporco di Hibernate in questa risposta SO: JPA con inserto HIBERNATE molto lento

— Volksman
fonte

3

E come tutti sappiamo, il miglioramento è proprio il motivo per cui JDO è stato adottato in modo così massiccio!

— Pascal Thivent,

15

Il FUD ben pubblicizzato e l'astroturfing eseguiti dai principali giocatori di Hibernate nei primi giorni in relazione a JDO sono a dir poco disonesti e disgustosi e senza dubbio hanno avuto qualche influenza sull'adozione di JDO. In questi giorni gli sviluppatori sanno che il miglioramento del codice byte non è affatto un problema e spesso lo usano per molti scopi diversi dalla persistenza. La nuova libreria di miglioramento del codice byte ASM è così veloce che non hai nemmeno il tempo di fare un respiro prima di farlo.

— Volksman

7

Il fallimento di JDO è stato previsto sin dall'inizio ( javalobby.org/forums/thread.jspa?forumID=46&threadID=1326 ) e prima di Hibernate in modo da non poter incolpare Hibernate per quello. Hibernate / Toplink è riuscito dove i giocatori di Sun e JDO (e dei loro OODBMS) hanno fallito perché erano risposte migliori in quel momento, non a causa del marketing e del FUD. Periodo. Chi se ne frega se ASM è velocissimo oggi , non era lì 5+ anni fa, quando necessario e JDO perso semplicemente la battaglia. JDO è concettualmente superiore? Peccato, non è riuscito ad avere un'implementazione del vincitore in tempo (e non tornerà a causa dell'APP).

— Pascal Thivent

2

Per illustrare le mie parole (un altro post che illustra il dolore che le persone provavano durante lo sviluppo o perché Hibernate ha vinto la battaglia): mail-archive.com/open-jpa-dev@incubator.apache.org/… . Mi sembra ovvio che reflection / cglib sia stata una risposta pratica ai problemi delle persone (e alla gente non importa se un'API è concettualmente superiore se è un dolore da usare) e non vedo alcun giocatore chiave di Hibernate qui, solo utenti . Quindi alla fine mi chiedo chi stia effettivamente diffondendo FUD ...

— Pascal Thivent

7

Bene, questo non è certamente come ai vecchi tempi in cui ci sarebbero stati almeno 17 diversi post FUD Hibernate pro (ma provenienti solo da 3 indirizzi IP diversi. Do the maths people =)).

— Volksman,

54

Di recente ho valutato e scelto un framework di persistenza per un progetto java e i miei risultati sono i seguenti:

Quello che vedo è che il supporto a favore di JDO è principalmente:

puoi usare fonti di dati non sql, db4o, hbase, ldap, bigtable, couchdb (plugin per cassandra) ecc.
puoi passare facilmente da un'origine dati sql a non sql e viceversa.
nessun oggetto proxy e quindi meno problemi per quanto riguarda le implementazioni di hashcode () e equals ()
più POJO e quindi meno soluzioni alternative necessarie
supporta più relazioni e tipi di campi

e il supporto a favore dell'APP è principalmente:

più popolare
jdo è morto
non utilizza il miglioramento del bytecode

Sto vedendo molti post pro-JPA di sviluppatori JPA che chiaramente non hanno usato JDO / Datanucleus offrendo argomenti deboli per non usare JDO.

Inoltre sto vedendo molti post degli utenti JDO che sono migrati a JDO e di conseguenza sono molto più felici.

Per quanto riguarda il fatto che JPA sia più popolare, sembra che ciò sia dovuto in parte al supporto del fornitore RDBMS piuttosto che a un livello tecnicamente superiore. (A me sembra VHS / Betamax).

JDO e la sua implementazione di riferimento Datanucleus non è chiaramente morto, come dimostra l'adozione da parte di Google di GAE e lo sviluppo attivo sul codice sorgente (http://sourceforge.net/projects/datanucleus/).

Ho visto una serie di lamentele riguardo a JDO a causa del miglioramento del bytecode, ma non ho ancora spiegato perché sia male.

In effetti, in un mondo che sta diventando sempre più ossessionato dalle soluzioni NoSQL, JDO (e l'implementazione del datanucleus) sembra una scommessa molto più sicura.

Ho appena iniziato a utilizzare JDO / Datanucleus e l'ho configurato in modo da poter passare facilmente dall'uso di db4o a mysql. È utile per lo sviluppo rapido utilizzare db4o e non doversi preoccupare troppo dello schema DB e quindi, una volta stabilizzato lo schema da distribuire in un database. Sono anche fiducioso che in seguito, potrei distribuire tutta / parte della mia applicazione a GAE o sfruttare l'archiviazione distribuita / ridurre la mappa a livello di base / hadoop / cassandra senza troppo refactoring.

Ho trovato l'ostacolo iniziale di iniziare con Datanucleus un po 'complicato - La documentazione sul sito Web di Datanucleus è un po' difficile da affrontare - i tutorial non sono facili da seguire come mi sarebbe piaciuto. Detto questo, la documentazione più dettagliata sull'API e sulla mappatura è molto buona una volta superata la curva di apprendimento iniziale.

La risposta è, dipende da cosa vuoi. Preferirei avere codice più pulito, no-vendor-lock-in, più orientato al pojo, opzioni nosql versi più popolari.

Se vuoi la calda sensazione che stai facendo lo stesso della maggior parte degli altri sviluppatori / pecore, scegli JPA / ibernazione. Se vuoi guidare nel tuo campo, prova JDO / Datanucleus e decidi.

— Tom
fonte

9

In realtà, proprio come ho detto, stavo solo dando le mie impressioni su ciò che avevo scoperto mentre cercavo di scegliere una soluzione. Sì, sono un principiante in Java, perché dovrebbe essere quel relavent? D'altra parte, hai pubblicato diverse volte affermando la tua opinione che JDO è morto senza offrire fatti o prove a sostegno di ciò e non riconoscere le aree tecniche in cui JDO è chiaramente superiore. Ovviamente hai qualcosa di personale contro JDO / Datanucleus e stai usando questi thread come mezzo per perpetuare la tua posizione anti-JDO.

— Tom,

4

Pascal - stai litigando in un angolo qui. Penso che manchi il punto della sezione Pubblicità delle FAQ. L'OP ha chiesto pareri su 2 tecnologie. Invita coloro che sostengono entrambe le parti a farsi avanti e presentare le loro critiche / raccomandazioni costruttive. Per Andy / Datanucleus e altri utenti di JDO evidenziare i positivi di JDO e difendersi dalle critiche non è più pubblicità di qualcun altro che consiglia di utilizzare l'ibernazione.

— Tom,

5

Potresti fare bene a fare riferimento alla sezione delle FAQ che dice 'Be Nice' per i tuoi post su questo argomento sono stati accusatori, conflittuali o semplicemente maleducati. Il tuo primo è stato un commento sarcastico sul miglioramento. Secondo; fa irruzione sulle difficoltà delle prime implementazioni e non è più pertinente. Terzo è stato un beffardo beffardo e un insulto a coloro che potrebbero preferire non usare RDBMS. Quarto è stato sarcastico beffardo di qualcuno che ti ha opinioni diverse. Il quinto è stato un attacco; chiamandomi un pappagallo. Consideri questo 'Essere carini'?

— Tom,

3

Se hai avuto un'esperienza orribile con JDO, spiega cosa era orribile, ammetti che lo era con una versione precedente e che da allora le cose potrebbero essere migliorate. Devi anche riconoscere che gli altri potrebbero avere esigenze diverse per te. Solo perché sei "soddisfatto" di JPA e vuoi usare un RDBMS non significa che lo siano gli altri. Forse nella fretta di aumentare la tua reputazione hai perso di vista ciò che quella reputazione è lì per premiare? ps. Come sviluppatore dovresti davvero essere interessato al benessere di tali progetti in quanto questo è ciò che guida l'innovazione e riduce il blocco dei fornitori.

— Tom,

6

Questa sarà la mia risposta finale :) .. 1. Se non fosse un rimpianto chiedersi perché sollevarlo? 2. Non ho mai messo in dubbio la tua onestà, ho detto che non eri gentile con gli altri poster e che ti sei contraddetto. 3. nessuno ti ha suggerito di riassumere più di 8 anni, ma fai un backup delle tue affermazioni con fatti ed esempi piuttosto che dichiarazioni soggettive che potrebbero offendere. 5. Dove sono le posizioni "hibernate / jpa / jboss is evil" su questo post? Non lo vedo. Vedo solo i tuoi commenti anti-JDO.

— Tom,

40

Quale consiglieresti per un nuovo progetto?

Non consiglierei nessuno dei due! Usa i DAO di Spring JdbcTemplateinsieme a StoredProcedure, RowMappereRowCallbackHandler invece.

La mia esperienza personale con Hibernate è che il tempo risparmiato in anticipo è più che compensato dagli infiniti giorni che trascorrerai lungo la linea cercando di capire e debug di problemi come il comportamento inaspettato dell'aggiornamento a cascata.

Se si utilizza un DB relazionale, più il codice è vicino ad esso, maggiore è il controllo che si ha. Lo strato DAO di Spring consente un controllo accurato dello strato di mappatura, eliminando al contempo la necessità del codice della piastra di cottura. Inoltre, si integra nel livello di transazione di Spring, il che significa che è possibile aggiungere facilmente (tramite AOP) un comportamento transazionale complicato senza intromettersi nel codice (ovviamente, lo si ottiene anche con Hibernate).

— oxbow_lakes
fonte

4

questa è chiaramente una scelta di mappatura anti-oggetto-relazionale (ORM) guidata da grandi utenti e base di dati accumulata dai tempi ODBC (primi anni '90) (leggi legacy). Non vi è alcun motivo per non utilizzare JDBC (con o senza Spring) a meno che non si scelga di andare avanti e utilizzare il framework ORM. Pensa a quelle persone che un giorno hanno deciso di abbandonare FORTRAN per usare C o Pascal.

— topchef

23

@grigory - Parlo con molta esperienza di sprecare giorni cercando di capire i problemi di ibernazione, come aggiornamenti / eliminazioni a cascata, strutture di query ridicolmente inefficienti ecc. Le soluzioni ORM sono una "vittoria rapida" per coloro che non hanno una comprensione sufficiente dei database relazionali. Pertanto, è improbabile che la sola conoscenza di Hibernate si traduca in un buon prodotto finale. È la mia esperienza che, durante il ciclo di vita del progetto, Hibernate (e ORM per estensione) costa più tempo di quanto risparmi

— oxbow_lakes

8

mi dispiace che tu abbia avuto un'esperienza così scarsa con Hibernate. Vengo da database pesante / SQL / stored procedure / scuola JDBC me stesso. Non posso dire di essere convertito: ogni tecnologia sopra ha ancora un posto dove stare. Ma per applicazioni di livello generale Java a 3 livelli (indipendentemente dalle dimensioni) la prima scelta è una tecnologia ORM - preferibilmente JPA 2. Altri devono essere considerati in base a tali fattori codice legacy, integrazione, competenza, requisiti di batch pesanti, in tempo reale prestazioni ecc. che possono orientare (o meno) l'approccio verso stack tecnologici di database diversi.

— topchef

3

Sono completamente in disaccordo con la definizione di "vincita rapida" di cui sopra - basta afferrare Hibernate in Action ( stackoverflow.com/questions/96729/… ) (ed è JPA 1, con JPA 2 migliora solo) per comprendere appieno il potere e la copertura di questa tecnologia ha.

— topchef

7

Ho fatto un po 'di ricerche e Spring non consiglia più Spring DAO ( static.springsource.org/spring/docs/3.0.x/… ): "Lo stile di integrazione consigliato è di codificare DAO contro le semplici API Hibernate, JPA e JDO. lo stile precedente di utilizzo dei modelli DAO di Spring non è più raccomandato; "... È questo ciò che stavi raccomandando? Se è così, perché non lo raccomandano?

— Utente 1

23

JDO è morto

JDO in realtà non è morto, quindi per favore controlla i tuoi fatti. JDO 2.2 è stato rilasciato nell'ottobre 2008 JDO 2.3 è in fase di sviluppo.

Questo è sviluppato apertamente, sotto Apache. Sono state rilasciate più versioni di JPA e le specifiche ORM sono ancora in anticipo rispetto alle funzionalità proposte da JPA2

— DataNucleus
fonte

12

Le persone lo stanno sicuramente usando, come dimostrano i molti utenti che DataNucleus ha, non importa Xcalia, Kodo. Ti manca l'idea di base che JDO e JPA non stiano riempiendo lo stesso mercato. JPA è esclusivamente RDBMS. JDO è indipendente dal datastore e viene utilizzato per RDBMS, ma anche LDAP, XML, Excel, OODBM ecc.

— DataNucleus,

3

Mi piace il fattore non RDBMS, in particolare con l'aumento della popolarità delle soluzioni non RDBMS, è un grosso problema. Ciò significa che se l'APP non si evolve abbastanza velocemente, la disponibilità di un'alternativa "più aperta" e flessibile (JDO) significa che la popolarità dell'APP tenderà al ribasso, per necessità. Non importa le argomentazioni tecniche secondo cui JDO è più completo, superiore, maturo o quant'altro: non sarà una questione di preferenza . Ha senso che i fornitori di RDBMS si comportino in modo sospetto: i giorni del dominio del mercato RDBMS potrebbero volgere al termine.

— Manius,

Stiamo ancora usando JDO / DataNucleus nel 2019! Ora è fino alla versione 5.x e batte ancora Hibernate per produttività degli sviluppatori e prestazioni di runtime. Di recente ho dovuto fare un po 'di consulenza su una grande app web usando Hibernate e mi è stato ricordato il dolore che ho sofferto quando ero un utente e promotore di HIbernate attivo molti anni fa, un responsabile del team non mi ha creduto quando le ho detto che il suo campo BLOB veniva sempre preso con impazienza, anche se era contrassegnato come recuperato pigro. La completa mancanza di conoscenza "nascosta" da parte di un "esperto" autoproclamato esperto di Hibernate era tristemente preoccupante ma prevedibile.

— Volksman,

15

JDO ha funzionalità avanzate rispetto a JPA, vedere http://db.apache.org/jdo/jdo_v_jpa.html

— Sandeep Manne
fonte

Verissimo! Ma nessuno sembra saperlo ...

— marcolopes

10

Sto usando JPA (implementazione OpenJPA di Apache che si basa sul codice KODO JDO che ha più di 5 anni ed è estremamente veloce / affidabile). IMHO chiunque ti dica di eludere le specifiche ti sta dando dei cattivi consigli. Ci ho messo il tempo ed è stato sicuramente premiato. Con JDO o JPA puoi cambiare fornitore con modifiche minime (JPA ha una mappatura orm, quindi parliamo meno di un giorno per cambiare eventualmente fornitore). Se hai più di 100 tavoli come me, questo è enorme. Inoltre, puoi sfruttare la memorizzazione nella cache con gli sfratti della cache in termini di cluster ed è tutto positivo. SQL / Jdbc va bene per le query ad alte prestazioni, ma la persistenza trasparente è di gran lunga superiore per la scrittura di algoritmi e routine di input dei dati. Ho solo circa 16 query SQL in tutto il mio sistema (50k + righe di codice).

8

L'ho esaminato io stesso e non riesco a trovare una forte differenza tra i due. Penso che la grande scelta sia in quale implementazione si utilizza. Per quanto mi riguarda, ho preso in considerazione la piattaforma DataNucleus in quanto è un'implementazione agnostica di entrambi i data store.

— tapi
fonte

6

+1 per DataNucleus, non per la risposta.

— WolfmanDragon,

8

Chiunque dica che JDO è morto è un mostro FUD astroturfing e lo sanno.

JDO è vivo e vegeto. Le specifiche sono ancora più potenti, mature e avanzate rispetto all'APP molto più giovane e vincolato.

Se si desidera limitarsi solo a ciò che è disponibile nello standard JPA, è possibile scrivere su JPA e utilizzare DataNucleus come implementazione di persistenza ad alte prestazioni e più trasparente rispetto alle altre implementazioni di JPA. Ovviamente DataNucleus implementa anche lo standard JDO se si desidera la flessibilità e l'efficienza della modellazione offerte da JDO.

— Volksman
fonte

1

Oppure usi un'altra (buona) implementazione con una comunità molto più grande e di conseguenza più reattiva. Sì, anche alcune persone se ne occupano.

— Pascal Thivent,

1

E parli di FUD> :) Divertente.

— Pascal Thivent

2

Il tuo commento sembra presumere che non ho usato sia Hibernate che JDO.

— Volksman,

2

Questo thread sembra avere un sacco di riferimenti da un paio di persone su quanto sia grande DataNucleus. Per favore, non usare questo posto come piattaforma pubblicitaria.

— TM.

3

Niente di sorprendente da parte di Golfman che sta incollando sempre le stesse disperate cose di marketing in ogni thread che coinvolge JPA o DataNucleus (che usa dal 1996 , prima ancora che esistesse !).

— Pascal Thivent,

2

Ho usato Hibernate (implementazione JPA) e JPOX (implementazione JDO) nello stesso progetto. JPOX ha funzionato bene, ma si è imbattuto in bug abbastanza rapidamente, là dove alcune funzionalità del linguaggio Java 5 non supportavano al momento. Ha avuto problemi a giocare bene con le transazioni XA. Stavo generando lo schema del database dagli oggetti JDO. Voleva connettersi a un database ogni volta che è fastidioso se la tua connessione Oracle non funziona.

Siamo quindi passati a Hibernate. Ci siamo divertiti un po 'con il solo utilizzo di JPA per un po', ma per eseguire il mapping era necessario utilizzare alcune delle funzionalità specifiche di Hibernate. L'esecuzione dello stesso codice su più database è molto semplice. L'ibernazione sembra memorizzare gli oggetti nella cache in modo aggressivo o a volte hanno solo strani comportamenti di memorizzazione nella cache. Esistono alcuni costrutti DDL che Hibernate non è in grado di gestire e pertanto sono definiti in un file aggiuntivo che viene eseguito per inizializzare il database. Quando ho riscontrato un problema con l'ibernazione, spesso ci sono molte persone che hanno riscontrato lo stesso problema, il che rende più facile cercare su google le soluzioni. Infine, Hibernate sembra essere ben progettato e affidabile.

Alcuni altri rispondenti hanno suggerito di usare solo SQL. Il vero caso d'uso killer per la mappatura relazionale degli oggetti è il test e lo sviluppo. I database creati per gestire grandi volumi di dati sono in genere costosi o difficili da installare. Sono difficili da testare. Esistono molti database Java in memoria che possono essere utilizzati per testare, ma in genere sono inutili per la produzione. Essere in grado di utilizzare un database reale, ma limitato, aumenterà la produttività dello sviluppo e l'affidabilità del codice.

— Sean McCauliff
fonte

1

Per quanto ne so, JPOX ha cambiato nome in DataNucleus (e da allora ha avuto versioni).

— Donal Fellows,

2

Pensa che scoprirai che DataNucleus ha molti meno bug aperti rispetto agli altri software a cui ti riferisci. Pensa che scoprirai anche che lo sviluppo di DataNucleus sta riducendo il numero di bug a una velocità maggiore rispetto a quella di altri software.

— DataNucleus,

1

Nel maggio 2012 ho realizzato una WebApp di esempio che utilizza JDO 3.0 e DataNucleus 3.0: dai un'occhiata a quanto è pulito: https://github.com/TorbenVesterager/BadAssWebApp

Va bene forse è un po 'troppo pulito, perché uso i POJO sia per il database che per il client JSON, ma è divertente :)

PS: contiene alcune annotazioni SuppressWarnings (sviluppato in IntelliJ 11)

— Torben Vesterager
fonte