定义仓库接口
要定义一个仓库接口，首先需要定义一个特定于领域类的仓库接口。该接口必须扩展 Repository 并指定领域类和 ID 类型。如果你想为该领域类型暴露 CRUD 方法，可以扩展 CrudRepository 或其变体，而不是 Repository。
微调仓库定义
你可以通过以下几种方式开始使用你的存储库接口。
典型的方法是扩展 CrudRepository，它为你提供了 CRUD 功能的方法。CRUD 代表创建（Create）、读取（Read）、更新（Update）和删除（Delete）。在 3.0 版本中，我们还引入了 ListCrudRepository，它与 CrudRepository 非常相似，但对于那些返回多个实体的方法，它返回的是一个 List 而不是 Iterable，你可能会觉得这更容易使用。
如果你正在使用响应式存储，根据你使用的响应式框架，你可能会选择 ReactiveCrudRepository 或 RxJava3CrudRepository。
如果你使用的是 Kotlin，你可能会选择 CoroutineCrudRepository，它利用了 Kotlin 的协程。
此外，如果你需要允许指定 Sort 抽象方法，或者在第一种情况下允许指定 Pageable 抽象方法，你可以扩展 PagingAndSortingRepository、ReactiveSortingRepository、RxJava3SortingRepository 或 CoroutineSortingRepository。需要注意的是，与 Spring Data 3.0 之前的版本不同，各种排序存储库不再扩展它们各自的 CRUD 存储库。因此，如果你需要两者的功能，你需要同时扩展这两个接口。
如果您不想扩展 Spring Data 接口，也可以在您的仓库接口上使用 @RepositoryDefinition 注解。扩展其中一个 CRUD 仓库接口会暴露一组完整的方法来操作您的实体。如果您希望对暴露的方法进行选择性处理，可以将您想要暴露的方法从 CRUD 仓库复制到您的领域仓库中。在进行此操作时，您可以更改方法的返回类型。如果可能，Spring Data 将尊重该返回类型。例如，对于返回多个实体的方法，您可以选择 Iterable<T>、List<T>、Collection<T> 或 VAVR 列表。
如果你的应用程序中有许多仓库需要拥有相同的方法集合，你可以定义一个自己的基础接口来继承。这样的接口必须用 @NoRepositoryBean 进行注解。这样可以防止 Spring Data 尝试直接创建它的实例，并且由于它仍然包含一个泛型类型变量，无法确定该仓库的实体，从而导致失败。
以下示例展示了如何选择性地暴露 CRUD 方法（在本例中为 findById 和 save）：
@NoRepositoryBean
interface MyBaseRepository<T, ID> extends Repository<T, ID> {
Optional<T> findById(ID id);
<S extends T> S save(S entity);
}
interface UserRepository extends MyBaseRepository<User, Long> {
User findByEmailAddress(EmailAddress emailAddress);
}
在之前的示例中，你为所有领域仓库定义了一个通用的基础接口，并暴露了 findById(…) 和 save(…) 方法。这些方法会被路由到由 Spring Data 提供的你选择的存储库的基础实现中（例如，如果你使用 JPA，那么实现就是 SimpleJpaRepository），因为它们与 CrudRepository 中的方法签名匹配。因此，UserRepository 现在可以保存用户、通过 ID 查找单个用户，并触发查询以通过电子邮件地址查找 Users。
中间仓库接口使用 @NoRepositoryBean 进行标注。确保你将此注解添加到所有 Spring Data 不应在运行时创建实例的仓库接口上。
使用多个 Spring Data 模块的存储库
在应用程序中使用唯一的 Spring Data 模块会使事情变得简单，因为定义范围内的所有仓库接口都会绑定到该 Spring Data 模块。然而，有时应用程序需要使用多个 Spring Data 模块。在这种情况下，仓库定义必须区分持久化技术。当 Spring Data 在类路径上检测到多个仓库工厂时，它会进入严格的仓库配置模式。严格配置模式使用仓库或领域类的详细信息来决定仓库定义与哪个 Spring Data 模块绑定：
-
如果仓库定义扩展了特定模块的仓库，那么它就是特定 Spring Data 模块的有效候选。
-
如果领域类使用了特定模块的类型注解进行标注，那么它也是特定 Spring Data 模块的有效候选。Spring Data 模块既接受第三方注解（例如 JPA 的
@Entity），也提供自己的注解（例如 Spring Data MongoDB 和 Spring Data Elasticsearch 的@Document）。
以下示例展示了一个使用模块特定接口（在本例中为 JPA）的仓库：
示例 1. 使用模块特定接口的存储库定义
interface MyRepository extends JpaRepository<User, Long> { }
@NoRepositoryBean
interface MyBaseRepository<T, ID> extends JpaRepository<T, ID> { … }
interface UserRepository extends MyBaseRepository<User, Long> { … }
MyRepository 和 UserRepository 在其类型层次结构中扩展了 JpaRepository。它们是 Spring Data JPA 模块的有效候选者。
以下示例展示了一个使用泛型接口的仓库：
示例 2. 使用通用接口的仓储定义
interface AmbiguousRepository extends Repository<User, Long> { … }
@NoRepositoryBean
interface MyBaseRepository<T, ID> extends CrudRepository<T, ID> { … }
interface AmbiguousUserRepository extends MyBaseRepository<User, Long> { … }
AmbiguousRepository 和 AmbiguousUserRepository 在其类型层次结构中仅扩展了 Repository 和 CrudRepository。虽然在使用单一的 Spring Data 模块时这是可行的，但在多个模块的情况下，无法区分这些仓库应该绑定到哪个特定的 Spring Data。
下面的示例展示了一个使用带有注解的领域类的仓库：
示例 3. 使用带有注解的领域类定义仓库
interface PersonRepository extends Repository<Person, Long> { … }
@Entity
class Person { … }
interface UserRepository extends Repository<User, Long> { … }
@Document
class User { … }
PersonRepository 引用了 Person，而 Person 被 JPA 的 @Entity 注解标记，因此这个仓库显然属于 Spring Data JPA。UserRepository 引用了 User，而 User 被 Spring Data MongoDB 的 @Document 注解标记。
以下是一个不好的示例，展示了一个使用混合注解的领域类仓库：
示例 4. 使用混合注解的领域类定义仓库
interface JpaPersonRepository extends Repository<Person, Long> { … }
interface MongoDBPersonRepository extends Repository<Person, Long> { … }
@Entity
@Document
class Person { … }
这个示例展示了同时使用 JPA 和 Spring Data MongoDB 注解的领域类。它定义了两个仓库，JpaPersonRepository 和 MongoDBPersonRepository。一个用于 JPA，另一个用于 MongoDB。由于 Spring Data 无法区分这两个仓库，这将导致未定义的行为。
区分存储库的最后一种方式是通过指定存储库的基础包范围。基础包定义了扫描存储库接口定义的起点，这意味着存储库定义需要位于适当的包中。默认情况下，基于注解的配置使用配置类所在的包。而在基于 XML 的配置中，基础包是必须指定的。
以下示例展示了基于注解的基础包配置：
@EnableJpaRepositories(basePackages = "com.acme.repositories.jpa")
@EnableMongoRepositories(basePackages = "com.acme.repositories.mongo")
class Configuration { … }