2011-01-09 8 views
11

Per quanto riguarda un'applicazione Java EE Web che verrà servita da un server di applicazioni Java EE completo, ad es. GlassFish, qual è la migliore soluzione ORM? EJB 3 o Hibernate 3 E perché?EJB 3 o Hibernate 3

+1

Esistono molte altre soluzioni di persistenza che presentano vantaggi distinti; sembra che tu li abbia ignorati nella tua domanda, e quindi qualsiasi risposta a ciò che è il "migliore" è arbitraria. Probabilmente il meglio dipende dall'applicazione stessa, dagli sviluppatori che lo stanno scrivendo e dall'archivio dati utilizzato ... e non hai fornito informazioni su quelli – DataNucleus

risposta

27

Questi due sono completamente diversi.

EJB3 è un modello componente e non ha nulla a che fare direttamente con ORM. Aiuta a gestire facilmente le transazioni e offre un facile accesso al gestore di entità da JPA, che è una soluzione ORM standard in Java EE.

Hibernate (3) è in effetti una soluzione ORM, e come accade uno che implementa JPA.

Quindi una domanda più logica è se utilizzare le interfacce JPA standardizzate o utilizzare direttamente l'API core di Hibernate. Quindi una domanda successiva potrebbe essere se utilizzare JPA standalone o in combinazione con EJB 3.

La risposta dipende un po 'da quello che ti serve esattamente, ma in genere l'utilizzo di JPA in combinazione con EJB 3 è la soluzione più semplice. L'uso di JPA o Hibernate standalone richiede un codice molto più dettagliato e devi gestire manualmente le transazioni, il che può essere un problema.

JPA vs Hibernate è un altro dibattito. JPA ha il vantaggio di avere interfacce standardizzate, quindi è probabile che più sviluppatori lo conoscano. D'altra parte, le API native di Hibernate sono sempre un super set di quelle di JPA e quindi offrono più potenza.

In genere gli sviluppatori basano principalmente il proprio codice su JPA e quindi utilizzano alcune annotazioni di Hibernate o chiamate API dove ha senso. Nel 99,99% dei casi è supportato tale utilizzo API misto.

Si noti inoltre che Glassfish è in bundle con EclipseLink, non con Hibernate. EclipseLink è paragonabile a Hibernate ma lo precede con più di un decennio. Hibernate ha preso molto da EclipseLink (chiamato allora TopLink).

Vedi anche questa risposta che ho dato a una domanda simile: Database table access via JPA Vs. EJB in a Web-Application

-1

Sono simili; le specifiche 3.0 per EJB hanno preso molto da Hibernate e Spring.

Non ho metriche fisse per nessuno dei due per citare, ma direi che se si sta abbracciando Glassfish è ragionevole per me usare tutta la sua tecnologia. Perché introdurre un'altra dipendenza? Vedi se Glassfish può fare il lavoro per te.

5

quello che hai chiesto è che API è meglio: EJB3 (JPA) o Sospensione? L'ho detto perché stai chiedendo informazioni su EJB3 JPA (che è solo API) e Hibernate (che è implementazione e API). Pertanto, per confrontare le mele con le mele è necessario confrontare le API. Puoi scegliere tra API standard (JPA) e più potente (Hibernate).

Ma scegliendo JPA c'è un'altra scelta da fare: per la sua implementazione. Scegliendo Hibernate per l'implementazione, puoi sostanzialmente scartare la domanda poiché sono disponibili sia JPA che Hibernate.

Quindi la tua domanda cambierebbe: quale implementazione JPA dovrei scegliere (tra Hibernate, EclipseLink, OpenJPA, DataNucleus, ecc.)? ...

+0

Nota che * EJB3 (JPA) * potrebbe essere un po ' confusione. Suggerisce che EJB3 è un altro nome per JPA, ma questo non è il caso. Era già tecnicamente una specifica completamente separata in EJB 3.0, e questo è stato formalizzato nella versione 3.1 attuale di EJB. JPA non è sia tecnicamente che organizzativa una specifica completamente diversa. Non è possibile scambiare i termini in alcun modo. –

+0

Tutto quello che intendevo è seguire la terminologia nelle domande di Ehsun. Grazie per i chiarimenti però. – topchef

Problemi correlati