Ibernazione vs JPA vs JDO: pro e contro di ciascuno?[Chiuso]
https://stackoverflow.com/questions/530215
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
Ho familiarità con il concetto ORM e ho persino utilizzato nHibernate diversi anni fa per un progetto .NET;tuttavia, non ho tenuto il passo con l'argomento 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 allontanarmi da una serie di servizi web legacy.
Ho difficoltà a distinguere tra le specifiche JPA, cosa ottieni con la libreria Hibernate stessa e cosa ha da offrire JDO.
Quindi, capisco che la domanda sia un po' aperta, ma speravo di ottenere qualche opinione su:
- Quali sono i pro ed i contro di ognuno?
- Quale suggeriresti per un nuovo progetto?
- Ci sono determinate condizioni in cui avrebbe senso utilizzare un framework piuttosto che un altro?
Soluzione
Alcune note:
- JDO e JPA sono entrambe le specifiche, non implementazioni.
- L'idea è che si può scambiare le implementazioni JPA, se si limita il codice per utilizzare unico standard JPA. (Idem per JDO.)
- Hibernate può essere usato come una tale attuazione di JPA.
- Tuttavia, Hibernate fornisce un'API nativa, con le caratteristiche sopra ed oltre quella di JPA.
IMO, mi sento di raccomandare Hibernate.
Ci sono stati alcuni commenti / domande su ciò che si dovrebbe fare se si necessità per utilizzare le funzionalità di Hibernate-specifici. Ci sono molti modi per guardare a questo, ma il mio consiglio è:
-
Se non si è preoccupato dalla prospettiva di vendor tie-in, quindi effettuare la scelta tra Hibernate, e altre implementazioni JPA e JDO tra cui le estensioni specifiche vari vendor nel vostro processo decisionale .
-
Se siete preoccupati dalla prospettiva di vendor tie-in, e non è possibile utilizzare JPA senza ricorrere al fornitore estensioni specifiche, quindi non utilizzare JPA. (Idem per JDO).
In realtà, si avrà probabilmente bisogno di trade-off quanto si sono preoccupati dal fornitore tie-in contro il quanto avete bisogno di quelle estensioni specifiche del fornitore.
E ci sono anche altri fattori, come quanto bene / il vostro personale conoscere le rispettive tecnologie, quanto i prodotti avrà un costo di licenza, e la cui storia si crede a quello che sta per accadere in futuro per JDO e JPA.
Altri suggerimenti
Assicurati di valutare l'attuazione DataNucleus di JDO. Abbiamo iniziato con Hibernate perché sembrava di essere così popolare, ma ben presto si rese conto che non è una soluzione di persistenza trasparente al 100%. Ci sono troppi avvertimenti e la documentazione è pieno di 'se si dispone di questa situazione è necessario scrivere il codice come questo' che ha tolto il divertimento di modellare liberamente e codifica però vogliamo. JDO ha non mi fece adattare il mio codice o il mio modello per farlo 'opera correttamente'. Posso solo progettare e POJO semplice codice come se stavo per usarli 'a memoria' solo, ma li posso persistere in modo trasparente.
L'altro vantaggio di JDO / DataNucleus sopra ibernazione è che non ha tutto il tempo di riflessione corsa in testa ed è più efficiente della memoria perché utilizza tempo di costruzione valorizzazione bytecode (magari aggiungere 1 sec al vostro tempo di costruzione di un grande progetto) piuttosto che correre il tempo di riflessione proxy pattern alimentato di Hibernate.
Un'altra cosa che si potrebbe trovare fastidioso con Hibernate è che un riferimento si deve ciò che si pensa è l'oggetto ... è spesso un 'delega' per l'oggetto. Senza il beneficio di enhancement codice byte è richiesto lo schema proxy per consentire il caricamento a richiesta (cioè evitare tirando l'intero grafo di oggetti quando si tira in un oggetto di livello superiore). Siate pronti a sovrascrivere equals e hashCode perché l'oggetto pensi di riferimento è spesso solo un proxy per quell'oggetto.
Ecco un esempio di frustrazioni si otterrà con Hibernate che non sarà possibile ottenere con JDO:
http: //blog.andrewbeacock .com / 2008/08 / how-to-implementare-hibernate-safe-equals.html
http://burtbeckwith.com/blog/?p=53
Se vi piace di codifica a 'soluzioni', quindi, certo, Hibernate è per voi. Se apprezzate pulito puro, orientato agli oggetti, il modello di sviluppo guidato, dove trascorrere tutto il vostro tempo sulla modellazione, progettazione e codifica e nessuno di esso su brutti soluzioni poi passare qualche ora valutando JDO / DataNucleus . Le ore investite saranno rimborsati mille volte.
Aggiornamento febbraio 2017
Per un bel po 'di tempo DataNucleus' implementa lo standard di persistenza JPA, oltre alla persistenza di serie JDO così il porting di progetti JPA esistenti da Hibernate per DataNucleus dovrebbe essere molto semplice e si può ottenere tutti i benefici di DataNucleus sopra menzionati con molto poco cambia codice, se presente. Quindi, in termini della questione, la scelta di un particolare standard JPA (RDBMS solo) vs JDO (RDBMS + No SQL + ODBMSes + altri), DataNucleus supporta sia, Hibernate è limitato a JPA solo.
Performance aggiornamenti Hibernate DB
Un altro aspetto da prendere in considerazione quando si sceglie un ORM è l'efficienza del suo meccanismo di controllo sporca - che diventa molto importante quando è necessario costruire lo SQL per aggiornare gli oggetti che sono stati modificati nella transazione corrente - soprattutto quando ci sono un sacco di oggetti. C'è una descrizione tecnica dettagliata del meccanismo di controllo sporca di Hibernate in questo SO rispondere: JPA con Hibernate inserire molto lento
Recentemente ho valutato e scelto un framework di persistenza per un progetto Java e i miei risultati sono i seguenti:
Quello che vedo è che il sostegno è a favore di JDO è principalmente:
- puoi utilizzare origini 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 hashcode() ed equals()
- sono necessarie più POJO e quindi meno soluzioni alternative
- supporta più relazioni e tipi di campo
e il sostegno a favore di APP è principalmente:
- più popolare
- jdo è morto
- non utilizza il miglioramento del bytecode
Vedo molti post pro-JPA da parte di sviluppatori JPA che chiaramente non hanno utilizzato JDO/Datanucleus che offrono argomenti deboli per non utilizzare JDO.
Vedo anche molti post di utenti JDO che sono migrati a JDO e di conseguenza sono molto più felici.
Per quanto riguarda la maggiore popolarità di JPA, sembra che ciò sia dovuto in parte al supporto del fornitore RDBMS piuttosto che alla sua superiorità tecnica.(A me sembra VHS/Betamax).
JDO e la sua implementazione di riferimento Datanucleus non sono chiaramente morti, come dimostrato dall'adozione da parte di Google per GAE e dallo sviluppo attivo sul codice sorgente (http://sourceforge.net/projects/datanucleus/).
Ho visto numerose lamentele su JDO a causa del miglioramento del bytecode, ma ancora nessuna spiegazione del motivo per cui è dannoso.
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'utilizzo di db4o a mysql.Per uno sviluppo rapido è utile utilizzare db4o e non doversi preoccupare troppo dello schema del database e quindi, una volta stabilizzato lo schema, distribuirlo in un database.Sono anche fiducioso che in seguito potrei distribuire tutta/parte della mia applicazione su GAE o sfruttare l'archiviazione distribuita/ridurre la mappa a la hbase /hadoop/cassandra senza troppi refactoring.
Ho trovato l'ostacolo iniziale per iniziare con Datanucleus un po' complicato: la documentazione sul sito web di datanucleus è un po' difficile da comprendere, i tutorial non sono così facili da seguire come avrei voluto.Detto questo, la documentazione più dettagliata sull'API e sulla mappatura è molto utile una volta superata la curva di apprendimento iniziale.
La risposta è: dipende da cosa vuoi.Preferirei avere un codice più pulito, senza vincoli del fornitore, più orientato al pojo, opzioni NoSQL rispetto a più popolari.
Se vuoi la calda sensazione di stare facendo lo stesso della maggior parte degli altri sviluppatori/pecore, scegli JPA/hibernate.Se vuoi essere leader nel tuo campo, prova JDO/Datanucleus e prendi una decisione.
Quale suggeriresti per un nuovo progetto?
Vorrei suggerire né! Utilizzare JdbcTemplate Spring DAO insieme StoredProcedure, RowMapper e RowCallbackHandler invece.
La mia esperienza personale con Hibernate è che il tempo risparmiato up-front è più che compensata dalle interminabili giorni vi permetterà di trascorrere tutta la linea per cercare di capire e problemi di debug come comportamento di aggiornamento a cascata imprevisto.
Se si utilizza un DB relazionale quindi il più vicino il codice è ad esso, il più controllo che avete. strato DAO di Primavera permette un controllo preciso del livello di mappatura, mentre eliminando la necessità di codice standard. Inoltre, si integra in strato di transazione di primavera che significa che si può facilmente aggiungere (tramite AOP) comportamento transazionale complicata senza questa intrusione nel codice (naturalmente, si ottiene questo con Hibernate troppo).
JDO è morto
JDO non è morto in realtà quindi si prega di controllare i fatti. JDO 2.2 è stato rilasciato in ottobre 2008 JDO 2.3 è in fase di sviluppo.
Questa è sviluppato apertamente, sotto Apache. Più versioni di APP ha avuto, e la sua specifica ORM è ancora in anticipo anche le caratteristiche JPA2 proposti
JDO sta avendo funzioni avanzate di JPA vedere http://db.apache.org/jdo/ jdo_v_jpa.html
Sto usando JPA (attuazione OpenJPA da Apache che si basa sul codice KODO JDO che è 5+ anni ed estremamente veloce / affidabile). IMHO chi ti dice di bypassare le specifiche, ti dà un cattivo consiglio. Ho messo il tempo ed è stato sicuramente ricompensato. Con entrambi JDO o JPA si può cambiare fornitori con modifiche minime (APP ha mappatura ORM quindi stiamo parlando di meno di un giorno per cambiare eventualmente, fornitori). Se si dispone di più di 100 tabelle come faccio questo è enorme. Inoltre si ottiene built0in caching con sgomberi di cache di cluster-saggio e è tutto buono. SQL / JDBC è 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 + linee di codice).
Chiunque dica che JDO è morto è un maniaco del astroturfing FUD e loro lo sanno.
JDO è vivo e vegeto. La specifica è ancora più potente, maturo e avanzato rispetto l'APP molto più giovane e vincolato.
Se si vuole limitarsi a ciò che è disponibile solo nella norma APP è possibile scrivere per APP e utilizzare DataNucleus come ad alte prestazioni, implementazione di persistenza più trasparente rispetto alle altre implementazioni di JPA. Naturalmente DataNucleus implementa anche lo standard JDO se si desidera che la flessibilità e l'efficienza della modellazione che JDO porta.
Ho usato Hibernate (implementazione JPA) e JPOX (attuazione JDO) nello stesso progetto. JPOX funzionava male, ma ha incontrato bug abbastanza rapidamente, là dove alcuni Java 5 lingua dispone che non ha sostenuto in quel momento. Aveva problemi a giocare bello con le transazioni XA. Mi stava generando lo schema del database dagli oggetti JDO. Voleva connettersi a un database ogni volta che è fastidioso se la connessione Oracle non accade funzionare.
Siamo poi passati a Hibernate. Abbiamo toyed intorno con usando solo pura JPA per un po ', ma abbiamo bisogno di usare alcune delle caratteristiche specifiche Hibernate per fare la mappatura. Esegue lo stesso codice su più database è molto semplice. Hibernate sembra memorizzare nella cache gli oggetti in modo aggressivo o semplicemente hanno un comportamento di caching strano a volte. Ci sono alcuni DDL costruisce Hibernate non può gestire e quindi sono definiti in un file aggiuntivo che viene eseguito per inizializzare il database. Quando ho incontrato un problema Hibernate ci sono spesso molte persone che hanno eseguito lo stesso problema che rende googling per soluzioni più facili. Infine, Hibernate sembra essere ben progettata e affidabile.
Alcuni altri soccorritori hanno suggerito semplicemente usando SQL. Il caso d'uso vero killer per oggetto mapping relazionale è il test e lo sviluppo. I database che sono costruiti per gestire grandi volumi di dati sono in genere costosi e o sono difficili da installare. Sono difficili da testare con. Ci sono un sacco di database Java in memoria che possono essere utilizzati per controllare, ma sono in genere inutile per la produzione. Essere in grado di utilizzare un vero e proprio, ma limitato di database, aumenterà la produttività di sviluppo e l'affidabilità del codice.
Ho fatto una WebApp campione di maggio 2012 che utilizza JDO 3.0 & 3.0 DataNucleus - dare un'occhiata come è pulito: https://github.com/TorbenVesterager/BadAssWebApp
Ok forse è un po 'troppo pulito, perché io uso le POJO sia per il database e il client JSON, ma è divertente:)
PS: contiene qualche SuppressWarnings annotazioni (sviluppato in IntelliJ 11)
