回答:
HibernateはJPA実装ですが、Spring Data JPAはJPAデータアクセス抽象化です。Spring Data JPAは、JPAプロバイダーなしでは機能しません。
Spring Dataは、DDD RepositoryパターンまたはレガシーGenericDaoカスタム実装のソリューションを提供します。また、メソッド名の規則を使用してJPAクエリを生成することもできます。
Spring Dataでは、Hibernate、Eclipse Link、またはその他のJPAプロバイダーを使用できます。SpringまたはJava EEを使用することの非常に興味深い利点は、@Transactionalアノテーションを使用して宣言的にトランザクション境界を制御できることです。
Spring JDBCははるかに軽量であり、ネイティブクエリを対象としています。JDBCのみを使用する場合は、Spring JDBCを使用してJDBCの冗長性を処理することをお勧めします。
したがって、HibernateとSpring Dataは、競合他社ではなく補完的なものです。
ここで使用している3つの異なるものがあります。
では、Spring Data JPAと Spring + Hibernateがどのように機能するかを理解しましょう-
アプリケーションにSpring + Hibernateを使用しているとしましょう。これで、休止状態のSessionFactoryを使用してクラッド操作を作成するdaoインターフェースと実装が必要になります。たとえば、従業員クラスのdaoクラスを書いているとします。明日、アプリケーションで、他のエンティティの同様のクラッド操作を作成する必要があるかもしれません。したがって、ここで確認できる定型コードがたくさんあります。
Spring data jpaでは、リポジトリ（crudrepository、jparepository）を拡張してdaoインターフェースを定義できるようになり、実行時にdaoを実装できるようになりました。daoの実装を記述する必要はありません。このように、Spring Data JPAを使用すると、作業が簡単になります。
SpringJPAはライブを簡単にすることに同意しません。はい、それはいくつかのクラスを提供し、いくつかの単純なDAOを高速にすることができますが、実際には、それがあなたができるすべてです。findById（）または保存以外のことをしたい場合は、地獄を通過する必要があります：
なぜ自分のトランザクション管理が不利なのですか？Java 1.8では、インターフェースへのデフォルトのメソッド、Springアノテーションベースのトランザクションが許可されているため、simpleは機能しません。
残念ながら、SpringJPAはリフレクションに基づいており、メソッド名またはエンティティパッケージを注釈（！）にポイントする必要がある場合があります。これが、リファクタリングが大きなクラッシュを引き起こす理由です。残念ながら、@ TransactionalはプライマリDSでのみ機能します:(したがって、複数のDataSourceがある場合は、トランザクションがプライマリDSでのみ機能することを覚えておいてください。）
HibernateとSpring Data JPAの主な違いは何ですか？
HibernateはJPA互換、SpringJPA Spring互換です。SpringJPAをSpring-SpringBootなどで使用できる場合、HibernateJPA DAOをJavaEEまたはHibernateスタンドアロンで使用できます。
HibernateまたはSpring Data JPAを使用すべきでないのはいつですか？また、Spring JDBCテンプレートのパフォーマンスはHibernate / Spring Data JPAよりも優れているのでしょうか？
多くの結合を使用する必要がある場合、または複数のデータソース接続を持つSpringを使用する必要がある場合にのみ、Spring JDBCを使用してください。一般に、結合にはJPAを使用しないでください。
しかし、私の一般的なアドバイスは、新鮮なソリューションであるダオバブ（http://www.daobab.io）を使用することです。ダオバブは私のJavaであり、あらゆるJPAエンジンインテグレーターであり、私はそれがあなたのタスクに大いに役立つと信じています:)
Spring Dataは、JPA多くのことを抽象化し、永続化ストアへのアクセスにSpringの魔法（好むと好まざるとにかかわらず）をもたらす便利なライブラリです。主にリレーショナルデータベースを操作するために使用されます。つまり、findByNameOrderByAge(String name);実行時に解析され、適切なJPAクエリに変換されるようなメソッドを持つインターフェースを宣言することができます。
その上に配置JPAすると、その使用が魅力的になります。
SQLそれを知らないか、よく知らない新人開発者。これは災害のレシピですが、プロジェクトが些細なものであれば、彼らはそれを回避できます。
自分が何をしているかを理解しており、物事をすばやくスピンドルアップしたい経験豊富なエンジニア。これは実行可能な戦略かもしれません（しかし、さらに読む）。
での私の経験からSpring Data、その魔法は多すぎます（これはSpring一般的に当てはまります）。私は1つのプロジェクトでそれを頻繁に使用し始め、最終的にライブラリを自分の道から外すことができず、醜い回避策に終わったいくつかのコーナーケースにぶつかりました。後で他のユーザーの苦情を読んだところ、これらの問題はの典型的なものであることがわかりましたSpring Data。たとえば、何時間にも及ぶ調査/非難の原因となったこの問題を確認します。
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());
}
私は最終的にレベルを下げて使い始めましたJDBI-ボイラープレートからあなたを救うのにちょうど十分な「魔法」を備えた素晴らしいライブラリー。これにより、SQLクエリを完全に制御でき、ライブラリと戦う必要がほとんどなくなります。
Hibernateは、データベース内のJavaオブジェクトの仕様である「JPA」の実装です。
異なるORMSを切り替えることができるので、wrt JPAを使用することをお勧めします。
JDBCを使用する場合はSQLクエリを使用する必要があるため、SQLに精通している場合はJDBCを使用してください。