Qual è la differenza tra Hibernate e Spring Data JPA

Quali sono le principali differenze tra Hibernate e Spring Data JPA? Quando non dovremmo usare l'IBP Hibernate o Spring Data? Inoltre, quando il modello Spring JDBC può funzionare meglio di Hibernate / Spring Data JPA?

Hibernate è un'implementazione di JPA, mentre Spring Data JPA è un'astrazione di accesso ai dati JPA. Spring Data JPA non può funzionare senza un provider JPA.

Spring Data offre una soluzione al modello DDDRepository o alle GenericDaoimplementazioni personalizzate legacy . Può anche generare query JPA per tuo conto attraverso le convenzioni sui nomi dei metodi.

Con Spring Data, è possibile utilizzare Hibernate, Eclipse Link o qualsiasi altro provider JPA. Un vantaggio molto interessante dell'uso di Spring o Java EE è che puoi controllare i limiti delle transazioni in modo dichiarativo usando l' @Transactionalannotazione .

Spring JDBC è molto più leggero ed è destinato alle query native e se si intende utilizzare solo JDBC da solo, è meglio utilizzare Spring JDBC per gestire la verbosità JDBC.

Pertanto, Hibernate e Spring Data sono complementari piuttosto che concorrenti.

Ci sono 3 cose diverse che stiamo usando qui:

1. JPA: API di persistenza Java che forniscono specifiche per la persistenza, la lettura, la gestione dei dati dall'oggetto Java alle relazioni nel database.
2. Ibernazione: esistono vari provider che implementano jpa. Hibernate è uno di questi. Quindi abbiamo anche altri fornitori. Ma se si utilizza jpa con spring, in futuro è possibile passare a diversi provider.
3. Spring Data JPA: questo è un altro strato sopra jpa che la primavera fornisce per semplificarti la vita.

Quindi, consente di capire come APP dati di primavera e la primavera + Hibernate works-

Spring Data JPA:

Supponiamo che tu stia utilizzando spring + hibernate per la tua applicazione. Ora devi avere un'interfaccia e un'implementazione dao in cui dovrai scrivere l'operazione grezza usando SessionFactory di ibernazione. Supponiamo che tu stia scrivendo la classe dao per la classe Employee, domani nella tua applicazione potresti dover scrivere un'operazione grezza simile per qualsiasi altra entità. Quindi c'è un sacco di codice del boilerplate che possiamo vedere qui.

Ora i dati jpa di Spring ci consentono di definire le interfacce dao estendendo i suoi repository (crudrepository, jparepository) in modo da fornire un'implementazione dao in fase di esecuzione. Non è più necessario scrivere l'implementazione dao. Ecco come jpa dei dati di primavera ti semplifica la vita.

Non sono d'accordo che SpringJPA renda la vita facile. Sì, fornisce alcune classi e puoi velocizzare alcuni semplici DAO, ma in realtà è tutto ciò che puoi fare. Se vuoi fare qualcosa di più di findById () o salvare, devi attraversare l'inferno:

• nessun accesso EntityManager nelle classi org.springframework.data.repository (questa è la classe JPA di base!)
• gestione delle transazioni proprie (transazioni in sospensione non consentite)
• enormi problemi con più di una configurazione delle origini dati
• nessun pool di origini dati (HikariCP deve essere utilizzato come libreria di terze parti)

Perché la propria gestione delle transazioni è uno svantaggio? Poiché Java 1.8 consente i metodi predefiniti nelle interfacce, le transazioni basate sulle annotazioni di Spring, simple non funziona.

Sfortunatamente, SpringJPA si basa su riflessioni e talvolta è necessario puntare un nome di metodo o un pacchetto di entità in annotazioni (!). Ecco perché qualsiasi refactoring provoca un grosso incidente. Purtroppo, @Transactional funziona solo per DS primario :( Quindi, se hai più di una DataSource, ricorda: le transazioni funzionano solo per DS primario :)

Quali sono le principali differenze tra Hibernate e Spring Data JPA?

Hibernate è compatibile con JPA, compatibile con SpringJPA Spring. Il DAO HibernateJPA può essere utilizzato con JavaEE o Hibernate Standalone, quando SpringJPA può essere utilizzato in Spring, ad esempio SpringBoot

Quando non dovremmo usare l'IBP Hibernate o Spring Data? Inoltre, quando il modello Spring JDBC può funzionare meglio di Hibernate / Spring Data JPA?

Utilizzare Spring JDBC solo quando è necessario utilizzare molti join o quando è necessario utilizzare Spring con più connessioni all'origine dati. In genere, evitare JPA per Joins.

Ma il mio consiglio generale usa una nuova soluzione: Daobab ( http://www.daobab.io ). Daobab è il mio Java e qualsiasi integratore di motori JPA, e credo che ti aiuterà molto nelle tue attività :)

Spring Dataè una libreria di convenienza JPAche estrae molte cose e porta la magia della primavera (piaccia o no) all'accesso al negozio di persistenza. Viene utilizzato principalmente per lavorare con database relazionali. In breve, ti consente di dichiarare interfacce che hanno metodi del genere findByNameOrderByAge(String name);verranno analizzate in fase di esecuzione e convertite in appropriateJPA query .

Il suo posizionamento in cima JPArende il suo uso allettante per:

1. Sviluppatori principianti che non lo conoscono SQLo lo sanno male. Questa è una ricetta per il disastro, ma possono cavarsela se il progetto è banale.

2. Ingegneri esperti che sanno cosa fanno e vogliono dare una risposta rapida. Questa potrebbe essere una strategia praticabile (ma leggi oltre).

Dalla mia esperienza con Spring Data, la sua magia è troppo (questo è applicabile Springin generale). Ho iniziato a usarlo pesantemente in un progetto e alla fine ho affrontato diversi casi angolari in cui non riuscivo a togliermi la biblioteca e ho finito con brutte soluzioni. Successivamente ho letto i reclami degli altri utenti e mi sono reso conto che questi problemi sono tipici per Spring Data. Ad esempio, controlla questo problema che ha portato a ore di indagini / parolacce:

 public TourAccommodationRate createTourAccommodationRate(
        @RequestBody TourAccommodationRate tourAccommodationRate
    ) {
        if (tourAccommodationRate.getId() != null) {
            throw new BadRequestException("id MUST NOT be specified in a body during entry creation");
        }

        // This is an ugly hack required for the Room slim model to work. The problem stems from the fact that
        // when we send a child entity having the many-to-many (M:N) relation to the containing entity, its
        // information is not fetched. As a result, we get NPEs when trying to access all but its Id in the
        // code creating the corresponding slim model. By detaching the entity from the persistence context we
        // force the ORM to re-fetch it from the database instead of taking it from the cache

        tourAccommodationRateRepository.save(tourAccommodationRate);
        entityManager.detach(tourAccommodationRate);
        return tourAccommodationRateRepository.findOne(tourAccommodationRate.getId());
    }

Ho finito per passare al livello inferiore e ho iniziato a usare JDBI- una bella libreria con abbastanza "magia" per salvarti dalla piastra della caldaia. Con esso, hai il controllo completo sulle query SQL e non devi quasi mai combattere la libreria.

Hibernate è l'implementazione di "JPA" che è una specifica per gli oggetti Java nel Database.

Consiglierei di utilizzare wrt JPA in quanto è possibile passare da un ORMS all'altro.

Quando si utilizza JDBC, è necessario utilizzare le query SQL, quindi se si è esperti in SQL, selezionare JDBC.

Se preferisci semplicità e maggiore controllo sulle query SQL, suggerirei di utilizzare Spring Data / Spring JDBC.

È una buona quantità di curva di apprendimento in JPA e talvolta è difficile eseguire il debug di problemi. D'altra parte, mentre hai il pieno controllo su SQL, diventa molto più facile ottimizzare le query e migliorare le prestazioni. Puoi facilmente condividere il tuo SQL con DBA o qualcuno che abbia una migliore comprensione del database.