自定义仓库实现
Spring Data 提供了多种选项,可以通过少量编码创建查询方法。但当这些选项无法满足您的需求时,您还可以为存储库方法提供自定义实现。本节将介绍如何实现这一点。
自定义单个仓库
为了丰富仓库的自定义功能,您首先需要定义一个片段接口以及该自定义功能的实现,如下所示:
interface CustomizedUserRepository {
void someCustomMethod(User user);
}
class CustomizedUserRepositoryImpl implements CustomizedUserRepository {
@Override
public void someCustomMethod(User user) {
// Your custom implementation
}
}
与片段接口对应的类名中最重要的部分是 Impl
后缀。你可以通过设置 @Enable<StoreModule>Repositories(repositoryImplementationPostfix = …)
来自定义特定存储的后缀。
历史上,Spring Data 自定义仓库实现的发现遵循了一种命名模式,该模式从仓库派生自定义实现类名,从而有效地允许单个自定义实现。
位于与仓库接口相同包中的类型,如果匹配 仓库接口名称 后跟 实现后缀,则被视为自定义实现,并将作为自定义实现处理。遵循该名称的类可能会导致不希望的行为。
我们认为单一自定义实现的命名方式已被弃用,并建议不要使用此模式。相反,建议迁移到基于片段的编程模型。
实现本身并不依赖于 Spring Data,可以是一个普通的 Spring Bean。因此,你可以使用标准的依赖注入行为来注入对其他 Bean 的引用(例如 JdbcTemplate
),参与切面等等。
然后你可以让你的仓库接口继承片段接口,如下所示:
interface UserRepository extends CrudRepository<User, Long>, CustomizedUserRepository {
// Declare query methods here
}
通过将你的存储库接口扩展片段接口,可以将 CRUD 操作和自定义功能结合起来,并使其可供客户端使用。
Spring Data 仓库通过使用片段来实现,这些片段形成了仓库的组合。片段包括基础仓库、功能方面(例如 Querydsl)以及自定义接口及其实现。每次向仓库接口添加一个接口时,都会通过添加一个片段来增强组合。每个 Spring Data 模块都提供基础仓库和仓库方面的实现。
以下示例展示了自定义接口及其实现:
interface HumanRepository {
void someHumanMethod(User user);
}
class HumanRepositoryImpl implements HumanRepository {
@Override
public void someHumanMethod(User user) {
// Your custom implementation
}
}
interface ContactRepository {
void someContactMethod(User user);
User anotherContactMethod(User user);
}
class ContactRepositoryImpl implements ContactRepository {
@Override
public void someContactMethod(User user) {
// Your custom implementation
}
@Override
public User anotherContactMethod(User user) {
// Your custom implementation
}
}
以下示例展示了一个扩展 CrudRepository
的自定义仓库接口:
interface UserRepository extends CrudRepository<User, Long>, HumanRepository, ContactRepository {
// Declare query methods here
}
存储库可能由多个自定义实现组成,这些实现按照其声明的顺序导入。自定义实现的优先级高于基础实现和存储库切面。这种排序方式允许你覆盖基础存储库和切面的方法,并在两个片段提供相同方法签名时解决歧义。存储库片段不仅限于在单个存储库接口中使用。多个存储库可以使用一个片段接口,从而让你在不同的存储库之间重用自定义逻辑。
以下示例展示了一个仓库片段及其实现:
interface CustomizedSave<T> {
<S extends T> S save(S entity);
}
class CustomizedSaveImpl<T> implements CustomizedSave<T> {
@Override
public <S extends T> S save(S entity) {
// Your custom implementation
}
}
以下示例展示了一个使用前面仓库片段的仓库:
interface UserRepository extends CrudRepository<User, Long>, CustomizedSave<User> {
}
interface PersonRepository extends CrudRepository<Person, Long>, CustomizedSave<Person> {
}
配置
存储库基础设施尝试通过扫描在发现存储库的包下的类来自动检测自定义实现片段。这些类需要遵循命名约定,默认附加后缀为 Impl
。
以下示例展示了一个使用默认后缀的仓库,以及一个为后缀设置自定义值的仓库:
示例 1. 配置示例
- Java
- XML
@EnableJdbcRepositories(repositoryImplementationPostfix = "MyPostfix")
class Configuration { … }
<repositories base-package="com.acme.repository" />
<repositories base-package="com.acme.repository" repository-impl-postfix="MyPostfix" />
前面示例中的第一个配置尝试查找名为 com.acme.repository.CustomizedUserRepositoryImpl
的类,以作为自定义仓库实现。第二个示例尝试查找 com.acme.repository.CustomizedUserRepositoryMyPostfix
。
歧义解决
如果在不同的包中找到具有相同类名的多个实现,Spring Data 会使用 bean 名称来标识要使用哪个实现。
给定前面展示的 CustomizedUserRepository
的两个自定义实现,第一个实现被使用。它的 bean 名称为 customizedUserRepositoryImpl
,这与片段接口的名称(CustomizedUserRepository
)加上后缀 Impl
相匹配。
示例 2. 模糊实现的解析
package com.acme.impl.one;
class CustomizedUserRepositoryImpl implements CustomizedUserRepository {
// Your custom implementation
}
package com.acme.impl.two;
@Component("specialCustomImpl")
class CustomizedUserRepositoryImpl implements CustomizedUserRepository {
// Your custom implementation
}
如果你在 UserRepository
接口上使用 @Component("specialCustom")
注解,那么 bean 名称加上 Impl
就会与在 com.acme.impl.two
中定义的仓库实现相匹配,并且会使用该实现而不是第一个。
手动配置
如果你的自定义实现仅使用基于注解的配置和自动装配,前面展示的方法会很好地工作,因为它被视为任何其他 Spring bean。如果你的实现片段 bean 需要特殊装配,你可以声明该 bean 并根据前面章节中描述的约定为其命名。然后,基础设施将通过名称引用手动定义的 bean 定义,而不是自己创建。以下示例展示了如何手动装配自定义实现:
示例 3. 手动连接自定义实现
- Java
- XML
class MyClass {
MyClass(@Qualifier("userRepositoryImpl") UserRepository userRepository) {
…
}
}
<repositories base-package="com.acme.repository" />
<beans:bean id="userRepositoryImpl" class="…">
<!-- further configuration -->
</beans:bean>
使用 spring.factories 注册片段
正如在配置部分中已经提到的,基础设施只会自动检测存储库基础包内的片段。因此,如果片段位于其他位置或希望通过外部存档贡献,并且它们不共享相同的命名空间,那么这些片段将不会被找到。在 spring.factories
中注册片段可以让你绕过这一限制,具体解释见下一节。
假设你希望为你的组织提供一种自定义的搜索功能,该功能可以跨多个存储库使用,并利用文本搜索索引。
首先,您需要的是片段接口。请注意泛型参数 <T>
,它将片段与仓库域类型对齐。
package com.acme.search;
public interface SearchExtension<T> {
List<T> search(String text, Limit limit);
}
假设实际的全文搜索功能通过一个 SearchService
实现,该服务已注册为上下文中的一个 Bean
,因此你可以在 SearchExtension
实现中使用它。运行搜索所需的只是集合(或索引)名称以及一个对象映射器,该映射器将搜索结果转换为实际的领域对象,如下所示。
package com.acme.search;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.domain.Limit;
import org.springframework.data.repository.core.RepositoryMethodContext;
class DefaultSearchExtension<T> implements SearchExtension<T> {
private final SearchService service;
DefaultSearchExtension(SearchService service) {
this.service = service;
}
@Override
public List<T> search(String text, Limit limit) {
return search(RepositoryMethodContext.getContext(), text, limit);
}
List<T> search(RepositoryMethodContext metadata, String text, Limit limit) {
Class<T> domainType = metadata.getRepository().getDomainType();
String indexName = domainType.getSimpleName().toLowerCase();
List<String> jsonResult = service.search(indexName, text, 0, limit.max());
return jsonResult.stream().map(…).collect(toList());
}
}
在上面的示例中,RepositoryMethodContext.getContext()
用于检索实际方法调用的元数据。RepositoryMethodContext
暴露了附加到存储库的信息,例如域类型。在本例中,我们使用存储库的域类型来标识要搜索的索引名称。
暴露调用元数据的成本较高,因此默认情况下是禁用的。要访问 RepositoryMethodContext.getContext()
,你需要建议负责创建实际存储库的存储库工厂暴露方法元数据。
- 标记接口
- Bean 后处理器
将 RepositoryMetadataAccess
标记接口添加到片段实现中,将触发基础设施,并为使用该片段的仓库启用元数据暴露。
package com.acme.search;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.domain.Limit;
import org.springframework.data.repository.core.support.RepositoryMetadataAccess;
import org.springframework.data.repository.core.RepositoryMethodContext;
class DefaultSearchExtension<T> implements SearchExtension<T>, RepositoryMetadataAccess {
// ...
}
exposeMetadata
标志可以通过 BeanPostProcessor
直接在仓库工厂 bean 上设置。
import org.springframework.beans.factory.config.BeanPostProcessor;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.repository.core.support.RepositoryFactoryBeanSupport;
import org.springframework.lang.Nullable;
@Configuration
class MyConfiguration {
@Bean
static BeanPostProcessor exposeMethodMetadata() {
return new BeanPostProcessor() {
@Override
public Object postProcessBeforeInitialization(Object bean, String beanName) {
if(bean instanceof RepositoryFactoryBeanSupport<?,?,?> factoryBean) {
factoryBean.setExposeMetadata(true);
}
return bean;
}
};
}
}
请不要直接复制/粘贴上述代码,而是考虑您的实际使用场景,可能需要更细粒度的处理方式,因为上述代码将简单地为每个仓库启用标志。
在准备好片段声明和实现之后,你可以在 META-INF/spring.factories
文件中注册扩展,并在需要时进行打包。
com.acme.search.SearchExtension=com.acme.search.DefaultSearchExtension
现在你已经准备好使用你的扩展;只需将接口添加到你的仓库中即可。
package io.my.movies;
import com.acme.search.SearchExtension;
import org.springframework.data.repository.CrudRepository;
interface MovieRepository extends CrudRepository<Movie, String>, SearchExtension<Movie> {
}
自定义基础仓库
在上一节中描述的方法需要在自定义基础仓库行为时对每个仓库接口进行定制,以便所有仓库都受到影响。相反,若要为所有仓库更改行为,您可以创建一个扩展了特定持久化技术的仓库基类的实现。然后,该类将作为仓库代理的自定义基类,如下例所示:
class MyRepositoryImpl<T, ID>
extends SimpleJpaRepository<T, ID> {
private final EntityManager entityManager;
MyRepositoryImpl(JpaEntityInformation entityInformation,
EntityManager entityManager) {
super(entityInformation, entityManager);
// Keep the EntityManager around to used from the newly introduced methods.
this.entityManager = entityManager;
}
@Override
@Transactional
public <S extends T> S save(S entity) {
// implementation goes here
}
}
该类需要有一个超类的构造函数,该构造函数由特定于存储库的存储库工厂实现使用。如果存储库基类有多个构造函数,请重载接受 EntityInformation
加上特定于存储的基础设施对象(例如 EntityManager
或模板类)的那个构造函数。
最后一步是让 Spring Data 基础设施意识到自定义的仓库基类。在配置中,你可以通过使用 repositoryBaseClass
来实现这一点,如下例所示:
示例 4. 配置自定义仓库基类
- Java
- XML
@Configuration
@EnableJdbcRepositories(repositoryBaseClass = MyRepositoryImpl.class)
class ApplicationConfiguration { … }
<repositories base-package="com.acme.repository"
base-class="….MyRepositoryImpl" />