Spring Data JPAのCrudRepositoryインターフェースとJpaRepositoryインターフェースの違いは何ですか？

違いは何ですかCrudRepositoryとJpaRepositoryのインターフェイス春データJPAは？

ウェブで例を見ると、同じ意味で使われているのがわかります。

それらの違いは何ですか？

なぜどちらか一方を使いたいのですか？

JpaRepository拡張PagingAndSortingRepository順番に延びていますCrudRepository。

主な機能は次のとおりです。

• CrudRepository 主にCRUD機能を提供します。
• PagingAndSortingRepository ページネーションとレコードのソートを行うメソッドを提供します。
• JpaRepository は、永続コンテキストのフラッシュやバッチでのレコードの削除など、いくつかのJPA関連のメソッドを提供します。

上記の継承のため、 JpaRepositoryとのすべての機能を備えCrudRepositoryていPagingAndSortingRepositoryます。したがって、リポジトリがJpaRepositoryand によって提供される機能を必要としない場合はPagingAndSortingRepository、を使用してくださいCrudRepository。

ケンの答えは基本的に正しいですが、「なぜ他のものを使いたいのですか？」にチャイムを入れたいと思います。あなたの質問の一部。

基本

リポジトリ用に選択する基本インターフェースには、主に2つの目的があります。まず、Spring Dataリポジトリインフラストラクチャがインターフェースを見つけてプロキシ作成をトリガーできるようにし、インターフェースのインスタンスをクライアントに挿入します。2番目の目的は、追加のメソッドを宣言することなく、必要なだけの機能をインターフェースに取り込むことです。

共通のインターフェース

Spring Dataコアライブラリには、専用の機能セットを公開する2つの基本インターフェースが付属しています。

• CrudRepository -CRUDメソッド
• PagingAndSortingRepository-ページネーションとソートのメソッド（拡張CrudRepository）

ストア固有のインターフェース

個々のストアモジュール（JPAやMongoDBなど）は、これらの基本インターフェイスのストア固有の拡張機能を公開して、一部のストア固有を考慮したフラッシュや専用バッチ処理などのストア固有の機能にアクセスできるようにします。このための一例であるdeleteInBatch(…)のJpaRepositoryとは異なるあるdelete(…)ことがよりパフォーマンスであるが、（スペック定義ことなど）JPA定義カスケードを誘発しない副作用が付属して所定のエンティティを削除するためにクエリを使用しています。

これらの基本インターフェースは、基盤となる永続化テクノロジーをクライアントに公開し、それによってそれらとリポジトリ間の結合を強化するため、通常は使用しないことをお勧めします。さらに、基本的に「エンティティのコレクション」であるリポジトリの元の定義から少し離れます。したがって、可能であれば、そのままにしPagingAndSortingRepositoryます。

カスタムリポジトリベースインターフェース

提供される基本インターフェースの1つに直接依存することの欠点は2つあります。どちらも理論的なものと見なされるかもしれませんが、次のことに注意することが重要だと思います。

1. Spring Dataリポジトリインターフェースに応じて、リポジトリインターフェースをライブラリに結合します。私は、あなたはおそらくのような抽象化を使用しますと、これは特定の問題ではないと思いますPageか、Pageableとにかくあなたのコードで。Spring Dataはcommons-langやGuavaのような他の汎用ライブラリと何の違いもありません。それが妥当な利益を提供する限り、それは問題ありません。
2. egを拡張CrudRepositoryすることで、永続メソッドの完全なセットを一度に公開します。これはおそらくほとんどの状況でも問題ありませんが、たとえばReadOnlyRepository、save(…)およびのdelete(…)メソッドを含まないを作成するなど、公開するメソッドをより細かく制御したい場合がありますCrudRepository。

これらの欠点の両方に対する解決策は、独自のベースリポジトリインターフェイスまたはそれらのセットを作成することです。多くのアプリケーションで、私はこのようなものを見てきました：

interface ApplicationRepository<T> extends PagingAndSortingRepository<T, Long> { }

interface ReadOnlyRepository<T> extends Repository<T, Long> {

  // Al finder methods go here
}

最初のリポジトリインターフェースは、実際にはポイント1を修正するだけでなくLong、一貫性を保つためにIDタイプを結び付けるいくつかの汎用ベースインターフェースです。2番目のインターフェイスは通常、すべてのfind…(…)メソッドをコピーしCrudRepositoryてPagingAndSortingRepository持っていますが、操作するメソッドは公開していません。リファレンスドキュメントでそのアプローチの詳細をご覧ください。

要約-tl; dr

リポジトリの抽象化により、アーキテクチャと機能のニーズに完全に対応したベースリポジトリを選択できます。必要に応じて、提供されているものを使用し、必要に応じて独自のリポジトリベースインターフェイスを作成します。やむを得ない場合を除き、ストア固有のリポジ​​トリインターフェースには近づかないでください。

概要：

• PagingAndSortingRepositoryはCrudRepositoryを拡張します

• JpaRepositoryはPagingAndSortingRepositoryを拡張します

CrudRepositoryそれはあなたがあなた自身のメソッドを定義することなく、読み取り、更新、削除レコードを作成することができますので、インターフェースは、CRUD操作のための方法を提供します。

PagingAndSortingRepositoryは、ページネーションとソートを使用してエンティティを取得するために、追加のメソッドを提供します。

最後に、JPaRepositoryは、JPAに固有の機能をいくつか追加します。

Spring Data JPAを学習しています。それはあなたを助けるかもしれません：

すべての回答は、質問に対する十分な詳細を提供します。ただし、もう少し追加してみましょう。

なぜこれらのインターフェースを使用するのですか？

• これにより、Springはリポジトリインターフェースを見つけ、それらのプロキシオブジェクトを作成できます。
• いくつかの一般的な操作を実行できるメソッドを提供します（カスタムメソッドを定義することもできます）。簡単な操作を行うメソッドを作成（およびクエリと準備されたステートメントを定義してから、接続オブジェクトを使用してクエリを実行）するのは本当に面倒なので、この機能が大好きです。

どのインターフェースが何をするか：

• CrudRepository：CRUD関数を提供します
• PagingAndSortingRepository：ページネーションを行い、レコードをソートするメソッドを提供します
• JpaRepository：永続コンテキストのフラッシュやバッチでのレコードの削除など、JPA関連のメソッドを提供します

どのインターフェースをいつ使用するか：

http://jtuts.com/2014/08/26/difference-between-crudrepository-and-jparepository-in-spring-data-jpa/によると

一般的に最良のアイデアは、並べ替えとページングが必要かどうかに応じて、CrudRepositoryまたはPagingAndSortingRepositoryを使用することです。

JpaRepositoryは、可能であれば、それはあなたがJPAの永続化技術にレポジトリ結びつけるため、避けるべきである、とほとんどの場合、あなたはおそらく、それが提供する余分なメソッドを使用することはありません。