Qual è la differenza tra JPA e Hibernate?

Capisco che JPA 2 è una specifica e Hibernate è uno strumento per ORM. Inoltre, capisco che Hibernate ha più funzioni di JPA 2. Ma da un punto di vista pratico, qual è davvero la differenza?

Ho esperienza con iBatis e ora sto cercando di imparare Hibernate o JPA2. Ho preso il libro Pro JPA2 e continua a riferirsi a “fornitore JPA”. Per esempio:

Se pensi che una funzione debba essere standardizzata, dovresti parlare e richiederla al tuo provider JPA

Questo mi confonde quindi ho alcune domande:

  • Usando solo JPA2 posso recuperare i dati dal DB semplicemente annotando i miei POJO
  • Si suppone che JPA2 sia utilizzato con un “provider JPA”, ad esempio TopLink o Hibernate? In tal caso, qual è il vantaggio dell’utilizzo di JPA2 + Hibernate rispetto a JPA2 da solo o rispetto a Hibernate da solo?
  • Potete consigliare un buon libro pratico di JPA2. “Pro JPA2” sembra più una bibbia e un riferimento su JPA2 (non entra in Query fino alla metà successiva del libro). C’è un libro che adotta un approccio problema / soluzione per JPA2?

Come si afferma JPA è solo una specifica, il che significa che non c’è implementazione. Puoi annotare le tue lezioni quanto vuoi con le annotazioni JPA, ma senza un’implementazione non accadrà nulla. Pensa a JPA come alle linee guida da seguire o all’interfaccia, mentre l’implementazione di JPA di Hibernate è il codice che soddisfa l’API come definito dalle specifiche JPA e fornisce la funzionalità under the hood.

Quando si utilizza Hibernate con JPA, si sta effettivamente utilizzando l’implementazione Hibernate JPA. Il vantaggio di questo è che è ansible sostituire l’implementazione di JPA di Hibernate per un’altra implementazione delle specifiche JPA. Quando si utilizza Hibernate diritto, ci si sta bloccando nell’implementazione perché altri ORM potrebbero utilizzare metodi / configurazioni e annotazioni diversi, pertanto non è ansible passare a un altro ORM.

Per una descrizione più dettagliata leggi il mio post sul blog .

JPA è il ballo, Hibernate è il ballerino.

Alcune cose sono troppo difficili da comprendere senza una prospettiva storica della lingua e della comprensione del JCP.

Spesso ci sono terze parti che sviluppano pacchetti che svolgono una funzione o riempiono un vuoto che non fa parte del JDK ufficiale. Per vari motivi, la funzione può diventare parte di Java JDK tramite JCP (Java Community Process)

Hibernate (nel 2003) ha fornito un modo per astrarre SQL e consentire agli sviluppatori di pensare di più in termini di oggetti persistenti (ORM). Si notifica l’ibernazione sugli oggetti Entity e si genera automaticamente la strategia per mantenerli. Hibernate ha fornito un’implementazione per fare ciò e l’API per guidare l’implementazione tramite la configurazione XML o le annotazioni.

Il problema fondamentale ora è che il tuo codice diventa strettamente accoppiato con un fornitore specifico (Hibernate) per quello che molte persone pensavano dovesse essere più generico. Da qui la necessità di un’API di persistenza generica.

Nel frattempo, il JCP con molti input da Hibernate e altri fornitori di strumenti ORM stava sviluppando JSR 220 (Java Specification Request) che ha portato JPA 1.0 (2006) e infine JSR 317 che è JPA 2.0 (2009). Queste sono le specifiche di un’API Java Persistence generica. L’API è fornita nel JDK come un insieme di interfacce in modo che le classi possano dipendere da javax.persistence e non preoccuparsi del particolare fornitore che sta facendo il lavoro di persistenza degli oggetti. Questa è solo l’API e non l’implementazione. Hibernate diventa ora uno dei tanti fornitori che implementano le specifiche JPA 2.0. È ansible codificare verso JPA e scegliere qualsiasi fornitore ORM conforms alle proprie esigenze.

Ci sono casi in cui Hibernate può darti caratteristiche che non sono codificate in JPA. In questo caso, puoi scegliere di inserire un’annotazione specifica di Hibernate direttamente nella tua class poiché JPA non fornisce l’interfaccia per fare quella cosa.

Fonte: http://www.reddit.com/r/java/comments/16ovek/understanding_when_to_use_jpa_vs_hibernate/

JPA è l’interfaccia mentre Hibernate è l’implementazione.

Tradizionalmente ci sono state più soluzioni Java ORM:

  • hibernate
  • TopLink
  • JDO

ogni implementazione che definisce la propria definizione di mapping o API client. Il gruppo di esperti JPA ha raccolto il meglio di tutti questi strumenti e così hanno creato lo standard Java Persistence API.

Un’API di persistenza standard è molto conveniente dal punto di vista del cliente, rendendo relativamente semplice il passaggio da un’implementazione all’altra (anche se in pratica non è così semplice perché su progetti di grandi dimensioni è necessario comunque utilizzare specifiche funzionalità non standard) .

Lo standard JPA ha spinto la concorrenza ORM di Java a un nuovo livello e questo può solo portare a migliori implementazioni.

Come spiegato nel mio libro, Persistenza Java ad alte prestazioni , Hibernate offre funzionalità che non sono ancora supportate da JPA :

  • generatori di identificatori estesi ( hi / lo , raggruppati, pooled-lo )
  • dosaggio di istruzioni preparato trasparente
  • dichiarazioni CRUD ( @SQLInsert , @SQLUpdate , @SQLDelete ) personalizzabili
  • filtri di raccolta statici o dinamici (ad es. @FilterDef , @Filter , @Where ) e filtri di entity framework (es. @Where )
  • mappare le proprietà ai frammenti SQL (es. @Formula )
  • quadro immutabili (es. @Immutable )
  • più modalità flush (es. FlushMode.MANUAL , FlushMode.ALWAYS )
  • interrogare la cache di secondo livello con la chiave naturale di una determinata entity framework
  • Strategie di concorrenza della cache a livello di quadro (es. Cache(usage = CacheConcurrencyStrategy.READ_WRITE) )
  • aggiornamenti collettivi con versione tramite HQL
  • escludere i campi dal controllo di blocco ottimistico (ad esempio @OptimisticLock(excluded = true) )
  • blocco ottimistico senza versione (ad es. OptimisticLockType.ALL , OptimisticLockType.DIRTY )
  • supporto per saltare (senza attendere) richieste di blocco pessimistiche
  • supporto per Java 8 Data e ora
  • supporto per multitenancy
  • supporto per soft delete (es. @Where , @Filter )

Queste funzionalità extra consentono a Hibernate di soddisfare molti requisiti di persistenza richiesti dalle applicazioni aziendali di grandi dimensioni.

Dal Wiki .

Motivazione per la creazione dell’API Java Persistence

Molti sviluppatori Java aziendali utilizzano oggetti persistenti leggeri forniti da framework open source o oggetti di accesso ai dati invece di bean di quadro: i bean di quadro ei bean enterprise hanno la reputazione di essere troppo pesanti e complicati e potrebbero essere utilizzati solo nei server di applicazioni Java EE. Molte delle funzionalità dei framework di persistenza di terze parti sono state incorporate nell’API Java Persistence e, a partire dal 2006, progetti come Hibernate (versione 3.2) e Open-Source Version TopLink Essentials sono diventati implementazioni dell’API Java Persistence.

Come detto nella pagina JCP, il collegamento Eclipse è l’implementazione di riferimento per JPA. Dai un’occhiata a questa risposta per un po ‘di più su questo.

Lo stesso JPA ha caratteristiche che compenseranno un framework ORM standard. Poiché JPA fa parte delle specifiche Java EE, è ansible utilizzare solo JPA in un progetto e dovrebbe funzionare con qualsiasi server Java EE compatibile . Sì, questi server avranno le implementazioni per le specifiche JPA.

Hibernate è il framework ORM più popolare, una volta che il JPA è stato introdotto, Hibernate è conforms alle specifiche JPA . Oltre alla serie di specifiche di base che dovrebbe seguire l’ibernazione fornisce molte altre cose aggiuntive.

Hibernate è un provider JPA.

La pagina JPA Vs Hibernate di Krishna Srinivasan dice:

JPA è una specifica per l’accesso, la persistenza e la gestione dei dati tra oggetti Java e il database relazionale. Come la definizione dice la sua API, è solo la specifica. Non c’è implementazione per l’API. JPA specifica l’insieme di regole e linee guida per lo sviluppo delle interfacce che seguono lo standard. Dritto al punto: JPA è solo linee guida per implementare l’Object Relational Mapping (ORM) e non esiste un codice sottostante per l’implementazione. Dove come, Hibernate è l’effettiva implementazione delle linee guida JPA. Quando hibernate implementa la specifica JPA, questo sarà certificato dal gruppo JPA seguendo tutti gli standard menzionati nella specifica. Ad esempio, le linee guida JPA fornirebbero informazioni sulle funzionalità obbligatorie e opzionali da implementare come parte dell’implementazione JPA.

L’APP è solo una specifica che richiede un’implementazione concreta. L’ implementazione predefinita di Oracle fornisce ora “Ecliplink”. (Toplink è donato da Oracle a Eclipse Foundation per fondersi con eclipselink)

(Riferimento: http://www.oracle.com/technetwork/middleware/toplink/index-085257.html http://www.eclipse.org/org/press-release/20080317_Eclipselink.php )

Usando Eclipselink, si può essere sicuri che il codice è portabile a qualsiasi implementazione in caso di necessità. Hibernate è anche un’implementazione completa di JPA + MORE (Sort of JPA Plus). Hibernate è un super set di JPA con alcune funzionalità aggiuntive di Hibernate. Quindi l’applicazione sviluppata in Hibernate potrebbe non essere compatibile quando passata ad un’altra implementazione. Ancora ibernato è la scelta della maggior parte degli sviluppatori come implementazione JPA e ampiamente utilizzata.

Un’altra implementazione di JPA è OpenJPA (openjpa.apache.org) che è un’estensione dell’implementazione di Kodo.

JPA: è proprio come un’interfaccia e non ha alcuna implementazione concreta per utilizzare le funzioni presenti in JPA.

Ibernazione: è solo un provider JPA che ha l’implementazione delle funzioni in JPA e può avere alcune funzioni extra che potrebbero non essere presenti in JPA.

SUGGERIMENTO: puoi usare

  *combo 1* : JPA + JPA Provider(Hibernate) *combo 2* : only Hiberante which does not need any interface 

Combo 1 : viene utilizzato quando ritieni che il tuo letargo non stia dando prestazioni migliori e desideri cambiare il provider JPA in quel momento in cui non devi scrivere ancora il tuo JPA. Puoi scrivere un altro provider JPA … e puoi cambiarlo tutte le volte che puoi.

Combo 2 : è usato molto meno come quando non cambierai il tuo provider JPA ad ogni costo.

Visita http://blog-tothought.rhcloud.com//post/2 , dove la tua completa confusione sarà chiara.

JPA è l’interfaccia, Hibernate è un’implementazione di tale interfaccia.

JPA è una specifica per standardizzare le API ORM. Hibernate è un fornitore di un’implementazione JPA. Quindi, se utilizzi JPA con la sospensione, puoi utilizzare l’API JPA standard, la sospensione sarà sotto controllo, offrendo alcune funzioni non standard. Vedi http://docs.jboss.org/hibernate/stable/entitymanager/reference/en/html_single/ e http://docs.jboss.org/hibernate/stable/annotations/reference/en/html_single/

JPA è solo una specifica. Sul mercato ci sono molti venditori che implementano JPA. Diversi tipi di fornitori implementano JPA in modo diverso. così diversi tipi di fornitori offrono funzionalità diverse, quindi scegli il fornitore adatto in base alle tue esigenze.

Se si utilizza Hibernate o altri fornitori anziché JPA, non è ansible spostarsi facilmente in sospensione su EclipseLink o OpenJPA su Hibernate.Ma se si utilizza JPA di quanto non si deve modificare fornire in file XML di persistenza. La migrazione è facilmente ansible in JPA.

JPA è un’API, una delle quali Hibernate implements.Hibernate è precedente a JPA. Prima di JPA, si scrive codice di ibernazione nativo per fare il tuo ORM. JPA è solo l’interfaccia, quindi ora scrivi il codice JPA e devi trovare un’implementazione. Hibernate sembra essere un’implementazione.

Quindi le tue scelte sono: hibernate, toplink, ecc …

Il vantaggio di JPA è che ti consente di sostituire la tua implementazione, se necessario. Lo svantaggio è che l’hibernate nativo / toplink / etc … API può offrire funzionalità che le specifiche JPA non supportano.

Mentre JPA è la specifica, Hibernate è il fornitore di implementazione che segue le regole dettate nella specifica.

Java: la sua indipendenza non è solo dal sistema operativo, ma anche dal venditore.

Pertanto, dovresti essere in grado di distribuire l’applicazione su server di applicazioni diversi. JPA è implementato in qualsiasi server applicativo Java EE compatibile e consente di scambiare server delle applicazioni, ma anche l’implementazione sta cambiando. Un’applicazione Hibernate può essere più semplice da implementare su un server di applicazioni diverso.

JPA è una specifica implementata nel livello dati per eseguire operazioni DB, mappature O e altre attività richieste.

Poiché si tratta solo di una specifica , è necessario uno strumento per averlo implementato. Lo strumento può essere Hibernate, TopLink, iBatis, dati primaverili, ecc.

Non devi necessariamente richiedere JPA se stai utilizzando l’ibernazione nel tuo livello dati. Ma se si usa la specifica JPA per Hibernate, allora in futuro si passerà ad altri strumenti ORM come iBatis, TopLink, perché le specifiche sono comuni anche per gli altri.

* ( se ricordi, import javax.persistence.*; quando usi le annotazioni per il mapping OR (come @Id, @Column, @GeneratedValue ecc.) in Hibernate, è qui che stai usando JPA sotto Hibernate, puoi usare JPA’s @Query e altre funzionalità pure )

JPA è una specifica API Java che descrive la gestione dei dati relazionali nelle applicazioni che utilizzano la piattaforma Java. dove Hibernate è una libreria ORM (Object Relational Mapping) che segue le specifiche JPA.

Puoi pensare all’APP come a un insieme di regole implementato da Hibernate.

JPA è JSR cioè Specifica delle specifiche Java per implementare la mapping relazionale degli oggetti che non ha codice specifico per la sua implementazione. Definisce un certo insieme di regole per l’accesso, la persistenza e la gestione dei dati tra gli oggetti Java e il database relazionale. Con la sua introduzione, EJB è stato sostituito in quanto è stato criticato per essere considerato pesante dalla comunità degli sviluppatori Java. Hibernate è uno dei modi in cui JPA può essere implementato usando le linee guida. Hibernate è un servizio di persistenza e query Object / Relational ad alte prestazioni concesso sotto licenza GNU Lesser General Public License (LGPL) open source. Il vantaggio di questo è che tu può sostituire l’implementazione di Hibernate di JPA per un’altra implementazione delle specifiche JPA. Quando si utilizza Hibernate diritto, ci si sta bloccando nell’implementazione perché altri ORM potrebbero utilizzare metodi / configurazioni e annotazioni diversi, pertanto non è ansible passare a un altro ORM.

L’APP è solo una specifica che richiede un’implementazione concreta. L’implementazione predefinita fornita da oracle è “Eclipselink” ora. Toplink è donato da Oracle a Eclipse Foundation per fondersi con eclipselink.

Usando Eclipselink, si può essere sicuri che il codice è portabile a qualsiasi implementazione in caso di necessità. Hibernate è anche un’implementazione completa di JPA + MORE. Hibernate è un super set di JPA con alcune funzionalità aggiuntive di Hibernate. Quindi l’applicazione sviluppata in Hibernate potrebbe non essere compatibile quando passata ad altre implementazioni. Ancora ibernato è la scelta della maggior parte degli sviluppatori come implementazione JPA e ampiamente utilizzata.

Un’altra implementazione di JPA è OpenJPA, che è un’estensione dell’implementazione di Kodo.

JPA vs Hibernate

Provo a spiegare in parole molto semplici.

Supponiamo di aver bisogno di una macchina, come tutti sappiamo che sono diversi produttori di class A come MERCEDES, BMW, AUDI ecc.

Ora in sopra affermazione CAR (è una specifica) come ogni auto ha caratteristiche comuni come cosa con 4 ruote e può essere guidata su strada è l’auto … quindi è come JPA. E MERCEDES, BMW, AUDI ecc stanno semplicemente utilizzando la funzionalità di auto comune e aggiungendo funzionalità in base alla loro base di clienti, quindi stanno implementando le specifiche della macchina come ibernazione, iBATIS ecc.

Quindi, con queste caratteristiche comuni, jpa e hibernate sono solo un’implementazione in base al loro bisogno di jboss.

1 altra cosa

JPA include alcune proprietà di base quindi, in futuro, se si desidera passare la sospensione a qualsiasi altra implementazione, è ansible passare facilmente senza molto mal di testa e per quelle proprietà di base include le annotazioni JPA che possono funzionare per qualsiasi tecnologia di implementazione, query JPQL.

Quindi, principalmente, implementiamo l’ibernazione con la tecnologia del tipo JPA solo nel caso in cui desideriamo cambiare la nostra implementazione in base alle necessità del cliente e scriverai meno codice, in quanto alcune funzioni comuni sono coinvolte in JPA. Se qualcuno non è ancora chiaro, puoi commentare come nuovo su overflow dello stack.

Grazie

JPA è solo una specifica mentre Hibernate è uno dei provider JPA, cioè l’ibernazione sta implementando varie cose menzionate nel contratto JPA.

JPA o Java Persistence API è una specifica standard per implementazioni ORM mentre Hibernate è l’implementazione o la struttura ORM effettiva.

JPA è Java Persistence API. Quale specifica solo le specifiche per le API. Significa che l’insieme di regole e linee guida per la creazione delle API. Se dice un altro contesto, è un insieme di standard che fornisce l’involucro per la creazione di tali API, che può essere utilizzato per accedere all’object quadro dal database. JPA è fornito da Oracle. Quando avremo accesso ai database, abbiamo sicuramente bisogno della sua implementazione. Mezzi JPA specifica solo le linee guida per l’implementazione delle API. Hibernate è un fornitore / fornitore JPA responsabile dell’implementazione di tali API. Come Hibernate TopLink e Open JPA sono alcuni esempi di provider di API JPA. Quindi utilizziamo le API standard specificate da JPA attraverso l’ibernazione.

In termini figurativi, JPA è solo interfaccia, Hibernate / TopLink – class (es. Implementazione dell’interfaccia).

È necessario avere l’implementazione dell’interfaccia per utilizzare l’interfaccia. Ma puoi utilizzare l’interfaccia di class, ovvero utilizzare Hibernate tramite l’API JPA oppure puoi utilizzare direttamente l’implementazione, ovvero utilizzare Hibernate direttamente, non tramite pura API JPA.

Un buon libro su JPA è “Persistenza di Java ad alte prestazioni” di Vlad Mihalcea.