Spring Data JPA中的CrudRepository和JpaRepository

Question

Spring Data JPA CrudRepository和JpaRepository接口之间有什么区别？当我在网络上看到示例时，我发现它们在这里可以互换使用。它们之间有什么区别？您为什么要在另一个上使用？

Answer 1

Ken的回答基本上是正确的，但我想提一下“您为什么要在另一个上使用一个？” 您的问题的一部分。

基本

您为存储库选择的基本接口有两个主要目的。首先，您允许Spring Data存储库基础结构找到您的接口并触发代理创建，以便将接口实例注入客户端。第二个目的是在接口中引入所需的功能，而不必声明其他方法。

通用接口

Spring Data核心库附带两个基本接口，它们公开了一组专用功能：

CrudRepository -CRUD方法

PagingAndSortingRepository-分页和排序方法（扩展CrudRepository）

商店特定的界面

各个商店模块（例如，针对JPA或MongoDB的商店模块）公开了这些基本接口的特定于商店的扩展，以允许访问特定于商店的功能（例如冲洗或专用批处理），这些功能考虑了一些特定于商店的情况。这方面deleteInBatch(…)的一个示例与之JpaRepository不同，delete(…)因为它使用查询来删除给定的实体，该实体的性能更高，但具有不触发JPA定义的级联（如规范定义）的副作用。

我们通常建议不要使用这些基本接口，因为它们会将底层的持久性技术公开给客户端，从而加强了它们与存储库之间的耦合。另外，您与存储库的原始定义有所不同，该存储库基本上是“实体集合”。因此，如果可以，请继续PagingAndSortingRepository。

自定义存储库基础接口

直接取决于所提供的基本接口之一的缺点是双重的。他们都可以被认为是理论上的，但是我认为重要的是要意识到：

取决于Spring Data存储库接口，可将您的存储库接口耦合到库。我认为这不是一个特别的问题，因为您可能仍会在代码中使用Page或之类的抽象Pageable。Spring Data与其他通用库（如commons-lang或Guava）没有任何不同。只要提供合理的利益，就可以了。

通过扩展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，而且将ID类型绑定Long为保持一致性。第二个接口通常具有find…(…)从中复制的所有方法CrudRepository，PagingAndSortingRepository但没有公开操作方法。在参考文档中阅读有关该方法的更多信息。

存储库抽象使您可以选择完全由架构和功能需求驱动的基础存储库。如果适合，请使用开箱即用的提供的接口，并在必要时制作自己的存储库基础接口。除非不可避免，否则请远离商店特定的存储库接口。