web-dev-qa-db-ja.com

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

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

私がウェブ上で例を見たとき、私はそれらが一種の互換的に使われているのを見ます。それらの違いは何ですか?なぜあなたはもう片方を使いたいのですか?

490
kseeker

JpaRepository extends PagingAndSortingRepository は次に CrudRepository を拡張します。

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

  • CrudRepository は主にCRUD関数を提供します。
  • PagingAndSortingRepository はページ付けやレコードのソートを行うためのメソッドを提供します。
  • JpaRepository は永続コンテキストのフラッシュやレコードの一括削除などのJPA関連のメソッドをいくつか提供します。

上記の継承のため、JpaRepositoryCrudRepositoryPagingAndSortingRepositoryのすべての機能を持ちます。そのため、JpaRepositoryPagingAndSortingRepositoryが提供する関数をリポジトリに用意する必要がない場合は、CrudRepositoryを使用します。

685
Ken Chan

ケンの答えは基本的に正しいのですが、私は「なぜあなたはもう一方をもう片方に使いたいのですか?」について賛美したいと思います。あなたの質問の一部です。

基本

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

共通インターフェース

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

  • CrudRepository - CRUDメソッド
  • PagingAndSortingRepository - ページ割り付けとソートのためのメソッド(CrudRepositoryを拡張)

店舗固有のインターフェース

個々のストアモジュール(JPAやMongoDBなど)は、これらの基本インターフェイスのストア固有の拡張機能を公開して、フラッシュやストア固有の処理を考慮した専用のバッチ処理などのストア固有の機能にアクセスできるようにします。これの例は、JpaRepositorydeleteInBatch(…)delete(…)とは異なります。これは、指定されたエンティティを削除するためにクエリを使用する点でよりパフォーマンスが優れています。

基本的な永続化技術をクライアントに公開し、そのためそれらとリポジトリの間のカップリングを強化するため、これらの基本インタフェースを使用することをnotすることをお勧めします。さらに、基本的に「エンティティのコレクション」であるリポジトリの元の定義から少し離れています。もし可能なら、PagingAndSortingRepositoryのままにしてください。

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

提供されている基本インターフェースの1つに直接依存することのマイナス面は2つあります。どちらも理論的なものと見なすことができますが、以下の点に注意することが重要です。

  1. Spring Dataのリポジトリインターフェースによっては、リポジトリインターフェースをライブラリに結合します。 PagePageableのような抽象概念をコードに使用する可能性があるので、これは特定の問題ではないと思います。 Spring Dataはcommons-langやGuavaのような他の汎用ライブラリと何の違いもありません。それが合理的な利益をもたらす限り、それはちょうどいいです。
  2. たとえば、 CrudRepositoryでは、一度に完全な永続化メソッドのセットを公開します。 これはたいていの状況でもおそらく大丈夫ですが、メソッドの公開をもっときめ細かく制御したい状況に遭遇するかもしれません。 ReadOnlyRepositorysave(…)およびdelete(…)メソッドを含まないCrudRepositoryを作成する。

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

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

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

  // Al Finder methods go here
}

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

サマリー - tl; dr

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

339
Oliver Drotbohm

enter image description here

要約:

  • PagingAndSortingRepositoryはCrudRepositoryを拡張します

  • JpaRepositoryはPagingAndSortingRepositoryを拡張します

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

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

最後に JpaRepository はJPA特有の機能を追加します。

50

私は 'spring data jpa'を学んでいます。それはあなたを助けるかもしれません。 enter image description here

0
Feng Zhang