Was ist der Unterschied zwischen Hibernate und Spring Data JPA?

Was sind die Hauptunterschiede zwischen Hibernate und Spring Data JPA? Wann sollten wir Hibernate oder Spring Data JPA nicht verwenden? Wann kann die Spring JDBC-Vorlage eine bessere Leistung erbringen als Hibernate / Spring Data JPA?

Hibernate ist eine JPA-Implementierung, während Spring Data JPA eine JPA-Datenzugriffsabstraktion ist. Spring Data JPA kann ohne einen JPA-Anbieter nicht funktionieren.

Spring Data bietet eine Lösung für das DDD- RepositoryMuster oder die älteren GenericDaobenutzerdefinierten Implementierungen. Es kann auch JPA-Abfragen in Ihrem Namen durch Methodennamenkonventionen generieren.

Mit Spring Data können Sie Hibernate, Eclipse Link oder einen anderen JPA-Anbieter verwenden. Ein sehr interessanter Vorteil der Verwendung von Spring oder Java EE besteht darin, dass Sie Transaktionsgrenzen mithilfe der @TransactionalAnnotation deklarativ steuern können .

Spring JDBC ist viel leichter und für native Abfragen gedacht. Wenn Sie JDBC nur alleine verwenden möchten, ist es besser, Spring JDBC zu verwenden, um mit der JDBC-Ausführlichkeit umzugehen.

Daher ergänzen sich Hibernate- und Spring-Daten eher als Konkurrenten.

Es gibt 3 verschiedene Dinge, die wir hier verwenden:

1. JPA: Java-Persistenz-API, die Spezifikationen zum Speichern, Lesen und Verwalten von Daten von Ihrem Java-Objekt zu Beziehungen in der Datenbank bereitstellt.
2. Ruhezustand: Es gibt verschiedene Anbieter, die jpa implementieren. Der Winterschlaf ist einer von ihnen. Wir haben also auch andere Anbieter. Wenn Sie jedoch jpa mit spring verwenden, können Sie in Zukunft zu verschiedenen Anbietern wechseln.
3. Spring Data JPA: Dies ist eine weitere Schicht über jpa, die der Frühling bietet, um Ihnen das Leben zu erleichtern.

Lassen Sie uns also verstehen, wie die Federdaten jpa und spring + hibernate funktionieren.

Spring Data JPA:

Angenommen, Sie verwenden spring + hibernate für Ihre Anwendung. Jetzt benötigen Sie eine Dao-Schnittstelle und -Implementierung, in der Sie mit SessionFactory im Ruhezustand einen Rohbetrieb schreiben. Angenommen, Sie schreiben eine Dao-Klasse für die Employee-Klasse. Morgen müssen Sie in Ihrer Anwendung möglicherweise eine ähnliche Rohoperation für eine andere Entität schreiben. Es gibt also viel Code für das Boilerplate, den wir hier sehen können.

Mit Spring Data JPA können wir jetzt Dao-Schnittstellen definieren, indem wir die Repositorys (Crudrepository, Jparepository) erweitern, sodass Sie zur Laufzeit eine Dao-Implementierung erhalten. Sie müssen keine Dao-Implementierung mehr schreiben. So erleichtert Spring Data JPA Ihr Leben.

Ich bin anderer Meinung, SpringJPA macht das Leben einfach. Ja, es bietet einige Klassen und Sie können schnell ein einfaches DAO erstellen, aber tatsächlich ist es alles, was Sie tun können. Wenn Sie mehr als findById () tun oder speichern möchten, müssen Sie durch die Hölle gehen:

• Kein EntityManager-Zugriff in org.springframework.data.repository-Klassen (dies ist eine grundlegende JPA-Klasse!)
• eigenes Transaktionsmanagement (Transaktionen im Ruhezustand nicht zulässig)
• große Probleme mit mehr als einer Datenquellenkonfiguration
• Kein Datenquellen-Pooling (HikariCP muss als Drittanbieter-Bibliothek verwendet werden)

Warum ist das eigene Transaktionsmanagement ein Nachteil? Da Java 1.8 Standardmethoden für Schnittstellen zulässt, funktionieren auf Spring Annotation basierende Transaktionen einfach nicht.

Leider basiert SpringJPA auf Überlegungen, und manchmal müssen Sie einen Methodennamen oder ein Entitätspaket in Anmerkungen (!) Verweisen. Das ist der Grund, warum jedes Refactoring einen großen Absturz verursacht. Leider funktioniert @Transactional nur für den primären DS :( Wenn Sie also mehr als eine DataSources haben, denken Sie daran - Transaktionen funktionieren nur für den primären DS :)

Was sind die Hauptunterschiede zwischen Hibernate und Spring Data JPA?

Der Ruhezustand ist JPA-kompatibel, SpringJPA Spring-kompatibel. Ihr HibernateJPA DAO kann mit JavaEE oder Hibernate Standalone verwendet werden, wenn SpringJPA beispielsweise in Spring - SpringBoot verwendet werden kann

Wann sollten wir Hibernate oder Spring Data JPA nicht verwenden? Wann kann die Spring JDBC-Vorlage eine bessere Leistung erbringen als Hibernate / Spring Data JPA?

Verwenden Sie Spring JDBC nur, wenn Sie viele Joins verwenden müssen oder wenn Sie Spring mit mehreren Datenquellenverbindungen verwenden müssen. Vermeiden Sie im Allgemeinen JPA für Joins.

Aber mein allgemeiner Rat, verwenden Sie eine frische Lösung - Daobab ( http://www.daobab.io ). Daobab ist mein Java und jeder JPA-Engine-Integrator, und ich glaube, es wird viel bei Ihren Aufgaben helfen :)

Spring Dataist eine Convenience-Bibliothek JPA, die darüber hinaus viele Dinge abstrahiert und Spring Magic (ob es Ihnen gefällt oder nicht) in den Persistence Store-Zugriff bringt. Es wird hauptsächlich für die Arbeit mit relationalen Datenbanken verwendet. Kurz gesagt, Sie können Schnittstellen findByNameOrderByAge(String name);mit solchen Methoden deklarieren, die zur Laufzeit analysiert und in entsprechende JPAAbfragen konvertiert werden.

Seine Platzierung auf JPAmacht seine Verwendung verlockend für:

1. Rookie-Entwickler, die es nicht SQLoder nur schlecht kennen. Dies ist ein Rezept für eine Katastrophe, aber sie können damit durchkommen, wenn das Projekt trivial ist.

2. Erfahrene Ingenieure, die wissen, was sie tun und die Dinge schnell auf den Kopf stellen wollen. Dies könnte eine praktikable Strategie sein (aber lesen Sie weiter).

Aus meiner Erfahrung mit Spring Dataist seine Magie zu viel (dies gilt Springim Allgemeinen). Ich fing an, es in einem Projekt stark zu nutzen, und traf schließlich mehrere Eckfälle, in denen ich die Bibliothek nicht aus dem Weg räumen konnte, und endete mit hässlichen Problemumgehungen. Später las ich die Beschwerden anderer Benutzer und stellte fest, dass diese Probleme typisch für sind Spring Data. Überprüfen Sie beispielsweise dieses Problem, das zu stundenlangen Ermittlungen / Fluchen führte:

 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());
    }

Am Ende ging ich auf ein niedrigeres Level und fing an zu benutzen JDBI- eine nette Bibliothek mit gerade genug "Magie", um dich vor dem Boilerplate zu retten. Damit haben Sie die vollständige Kontrolle über SQL-Abfragen und müssen fast nie gegen die Bibliothek kämpfen.

Hibernate ist die Implementierung von "JPA", einer Spezifikation für Java-Objekte in der Datenbank.

Ich würde empfehlen, wrt JPA zu verwenden, da Sie zwischen verschiedenen ORMS wechseln können.

Wenn Sie JDBC verwenden, müssen Sie SQL-Abfragen verwenden. Wenn Sie sich also mit SQL auskennen, entscheiden Sie sich für JDBC.

Wenn Sie Einfachheit und mehr Kontrolle bei SQL-Abfragen bevorzugen, würde ich Spring Data / Spring JDBC empfehlen.

Es ist eine gute Lernkurve in JPA und manchmal schwierig zu debuggen. Auf der anderen Seite ist es viel einfacher, die Abfrage zu optimieren und die Leistung zu verbessern, obwohl Sie die volle Kontrolle über SQL haben. Sie können Ihr SQL problemlos mit DBA oder jemandem teilen, der die Datenbank besser versteht.