Spring Data JPA中的CrudRepository和JpaRepository接口有什么区别？

本文翻译自：What is difference between CrudRepository and JpaRepository interfaces in Spring Data JPA?

What is the difference between CrudRepository and JpaRepository interfaces in Spring Data JPA? Spring Data JPA中的CrudRepository和JpaRepository接口有什么区别？

When I see the examples on the web, I see them there used kind of interchangeably. 当我在网上看到这些例子时，我看到它们在那里可以互换使用。 What is the difference between them? 他们之间有什么区别？ Why would you want to use one over the other? 你为什么要用一个而不是另一个？

---

#1楼

参考：https://stackoom.com/question/wnhe/Spring-Data-JPA中的CrudRepository和JpaRepository接口有什么区别

---

#2楼

JpaRepository extends PagingAndSortingRepository which in turn extends CrudRepository . JpaRepository扩展了PagingAndSortingRepository ，后者又扩展了CrudRepository 。

Their main functions are: 他们的主要职能是：

• CrudRepository mainly provides CRUD functions. CrudRepository主要提供CRUD功能。
• PagingAndSortingRepository provides methods to do pagination and sorting records. PagingAndSortingRepository提供了进行分页和排序记录的方法。
• JpaRepository provides some JPA-related methods such as flushing the persistence context and deleting records in a batch. JpaRepository提供了一些与JPA相关的方法，例如刷新持久化上下文和批量删除记录。

Because of the inheritance mentioned above, JpaRepository will have all the functions of CrudRepository and PagingAndSortingRepository . 由于上面提到的继承， JpaRepository将具有CrudRepository和PagingAndSortingRepository所有功能。 So if you don't need the repository to have the functions provided by JpaRepository and PagingAndSortingRepository , use CrudRepository . 所以，如果你不需要的仓库有提供的功能JpaRepository和PagingAndSortingRepository ，使用CrudRepository 。

---

#3楼

Ken's answer is basically right but I'd like to chime in on the "why would you want to use one over the other?" 肯的​​答案基本上是正确的，但我想谈谈“你为什么要用一个而不是另一个？” part of your question. 你问题的一部分。

Basics 基本

The base interface you choose for your repository has two main purposes. 您为存储库选择的基本接口有两个主要用途。 First, you allow the Spring Data repository infrastructure to find your interface and trigger the proxy creation so that you inject instances of the interface into clients. 首先，您允许Spring Data存储库基础结构找到您的接口并触发代理创建，以便将接口实例注入客户端。 The second purpose is to pull in as much functionality as needed into the interface without having to declare extra methods. 第二个目的是在界面中引入尽可能多的功能，而不必声明额外的方法。

The common interfaces 通用接口

The Spring Data core library ships with two base interfaces that expose a dedicated set of functionalities: Spring Data核心库附带了两个基本接口，它们公开了一组专用功能：

• CrudRepository - CRUD methods CrudRepository - CRUD方法
• PagingAndSortingRepository - methods for pagination and sorting (extends CrudRepository ) PagingAndSortingRepository - 分页和排序的方法（扩展CrudRepository ）

Store-specific interfaces 特定于商店的界面

The individual store modules (eg for JPA or MongoDB) expose store-specific extensions of these base interfaces to allow access to store-specific functionality like flushing or dedicated batching that take some store specifics into account. 各个商店模块（例如，用于JPA或MongoDB）公开这些基本接口的特定于商店的扩展，以允许访问特定于商店的功能，例如刷新或专用批处理，其中考虑了一些商店细节。 An example for this is deleteInBatch(…) of JpaRepository which is different from delete(…) as it uses a query to delete the given entities which is more performant but comes with the side effect of not triggering the JPA-defined cascades (as the spec defines it). 对于这样的一个例子是deleteInBatch(…)的JpaRepository其是从不同delete(…)因为它使用一个查询，以删除给定实体这是更高性能的但带有不触发JPA定义的级联的副作用（如规范定义它）。

We generally recommend not to use these base interfaces as they expose the underlying persistence technology to the clients and thus tighten the coupling between them and the repository. 我们通常建议不要使用这些基接口，因为它们将底层持久性技术暴露给客户端，从而加强它们与存储库之间的耦合。 Plus, you get a bit away from the original definition of a repository which is basically "a collection of entities". 另外，您从存储库的原始定义中获得了一点点，该存储库基本上是“实体集合”。 So if you can, stay with PagingAndSortingRepository . 因此，如果可以，请继续使用PagingAndSortingRepository 。

Custom repository base interfaces 自定义存储库基接口

The downside of directly depending on one of the provided base interfaces is two-fold. 直接依赖于所提供的基本接口之一的缺点是双重的。 Both of them might be considered as theoretical but I think they're important to be aware of: 它们都可能被认为是理论上的，但我认为重要的是要注意：

1. Depending on a Spring Data repository interface couples your repository interface to the library. 根据Spring Data存储库接口，将存储库接口与库耦合。 I don't think this is a particular issue as you'll probably use abstractions like Page or Pageable in your code anyway. 我不认为这是一个特殊的问题，因为你可能会在你的代码中使用像Page或Pageable这样的抽象。 Spring Data is not any different from any other general purpose library like commons-lang or Guava. Spring Data与commons-lang或Guava等任何其他通用库没有任何不同。 As long as it provides reasonable benefit, it's just fine. 只要它提供合理的利益，就可以了。
2. By extending eg CrudRepository , you expose a complete set of persistence method at once. 通过扩展例如CrudRepository ，您可以立即公开一组完整的持久性方法。 This is probably fine in most circumstances as well but you might run into situations where you'd like to gain more fine-grained control over the methods expose, eg to create a ReadOnlyRepository that doesn't include the save(…) and delete(…) methods of CrudRepository . 在大多数情况下这也许很好，但是你可能会遇到你想要对方法公开进行更细粒度控制的情况，例如创建一个不包含save(…)和delete(…)的ReadOnlyRepository delete(…) CrudRepository方法。

The solution to both of these downsides is to craft your own base repository interface or even a set of them. 这两个缺点的解决方案是制作您自己的基础存储库接口甚至是一组它们。 In a lot of applications I have seen something like this: 在很多应用程序中，我看到过这样的事情：

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

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

  // Al finder methods go here
}

The first repository interface is some general purpose base interface that actually only fixes point 1 but also ties the ID type to be Long for consistency. 第一个存储库接口是一些通用基本接口，实际上只修复了第1点，但也将ID类型Long为Long以保持一致性。 The second interface usually has all the find…(…) methods copied from CrudRepository and PagingAndSortingRepository but does not expose the manipulating ones. 第二个接口通常具有从CrudRepository和PagingAndSortingRepository复制的所有find…(…)方法，但不公开操作的方法。 Read more on that approach in the reference documentation . 在参考文档中阅读有关该方法的更多信息 。

Summary - tl;dr 摘要 - tl;博士

The repository abstraction allows you to pick the base repository totally driven by you architectural and functional needs. 存储库抽象允许您选择完全由您的架构和功能需求驱动的基础存储库。 Use the ones provided out of the box if they suit, craft your own repository base interfaces if necessary. 如果它们适合，使用开箱即用的那些，必要时制作您自己的存储库基础接口。 Stay away from the store specific repository interfaces unless unavoidable. 除非不可避免，否则请远离商店特定的存储库接口。

---

#4楼

Summary: 摘要：

• PagingAndSortingRepository extends CrudRepository PagingAndSortingRepository扩展了CrudRepository

• JpaRepository extends PagingAndSortingRepository JpaRepository扩展了PagingAndSortingRepository

The CrudRepository interface provides methods for CRUD operations, so it allows you to create, read, update and delete records without having to define your own methods. CrudRepository接口提供了CRUD操作的方法，因此它允许您创建，读取，更新和删除记录，而无需定义自己的方法。

The PagingAndSortingRepository provides additional methods to retrieve entities using pagination and sorting. PagingAndSortingRepository提供了使用分页和排序检索实体的其他方法。

Finally the JpaRepository add some more functionality that is specific to JPA. 最后， JpaRepository添加了一些特定于JPA的功能。

---

#5楼

I am learning Spring Data JPA. 我正在学习Spring Data JPA。 It might help you: 它可能会帮助你：