Spring Data JPA中的CrudRepository和JpaRepository

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但没有公开操作方法。在参考文档中阅读有关该方法的更多信息。存储库抽象使您可以选择完全由架构和功能需求驱动的基础存储库。如果适合，请使用开箱即用的提供的接口，并在必要时制作自己的存储库基础接口。除非不可避免，否则请远离商店特定的存储库接口。

Spring Data JPA中的CrudRepository和JpaRepository

3回答