自定义仓库实现
Spring Data 提供了多种选项,只需少量编码即可创建查询方法。但当这些选项不符合您的需求时,您也可以为仓库方法提供自己的自定义实现。本节介绍如何实现这一点。
自定义单个仓库
为了用自定义功能丰富仓库,您必须首先定义一个片段接口和该自定义功能的实现,如下所示
interface CustomizedUserRepository {
void someCustomMethod(User user);
}
class CustomizedUserRepositoryImpl implements CustomizedUserRepository {
@Override
public void someCustomMethod(User user) {
// Your custom implementation
}
}
与片段接口对应的类名中最重要的部分是 |
从历史上看,Spring Data 自定义仓库实现发现遵循一种命名模式,该模式从仓库派生自定义实现类名,实际上只允许单个自定义实现。 位于与仓库接口相同包中、名称匹配 *仓库接口名* 后跟 *实现后缀* 的类型,被视为自定义实现,并将被当作自定义实现处理。遵循此名称的类可能导致意外行为。 我们认为单自定义实现命名已被弃用,建议不要使用此模式。请改用基于片段的编程模型。 |
实现本身不依赖于 Spring Data,它可以是一个普通的 Spring Bean。因此,您可以使用标准的依赖注入行为来注入对其他 Bean 的引用(例如 JdbcTemplate
),参与 AOP 等等。
然后,您可以让您的仓库接口扩展该片段接口,如下所示
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
}
仓库可以由多个自定义实现组成,这些实现按其声明顺序导入。自定义实现比基础实现和仓库切面具有更高的优先级。此顺序允许您覆盖基础仓库和切面方法,并解决了如果两个片段贡献相同方法签名时的歧义。仓库片段不限于在单个仓库接口中使用。多个仓库可以使用同一个片段接口,从而允许您在不同的仓库之间重用自定义功能。
以下示例展示了仓库片段及其实现
save(…)
的片段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
的后缀。
以下示例展示了使用默认后缀的仓库和设置自定义后缀值的仓库
-
Java
-
XML
@EnableJpaRepositories(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
匹配。
class CustomizedUserRepositoryImpl implements CustomizedUserRepository {
// Your custom implementation
}
@Component("specialCustomImpl")
class CustomizedUserRepositoryImpl implements CustomizedUserRepository {
// Your custom implementation
}
如果您使用 @Component("specialCustom")
注解 UserRepository
接口,那么 Bean 名称加上 Impl
将匹配在 com.acme.impl.two
中为仓库实现定义的名称,并将使用它而不是第一个。
手动装配
如果您的自定义实现仅使用基于注解的配置和自动装配,那么前面展示的方法效果很好,因为它被当作任何其他 Spring Bean 处理。如果您的实现片段 Bean 需要特殊装配,您可以根据前面章节中描述的约定声明该 Bean 并命名它。然后,基础设施将按名称引用手动定义的 Bean 定义,而不是自己创建一个。以下示例展示了如何手动装配自定义实现
-
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>
,用于使片段与仓库域类型对齐。
public interface SearchExtension<T> {
List<T> search(String text, Limit limit);
}
假设实际的全文本搜索可以通过一个在上下文中注册为 Bean
的 SearchService
获得,这样您就可以在我们的 SearchExtension
实现中消费它。运行搜索所需的只是集合(或索引)名称以及一个将搜索结果转换为实际域对象的对象映射器,如下所述。
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
标记接口将触发基础设施并为使用该片段的仓库启用元数据公开。
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 {
// ...
}
可以通过 BeanPostProcessor
直接在仓库工厂 Bean 上设置 exposeMetadata
标志。
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
文件中注册该扩展,并在需要时将其打包。
META-INF/spring.factories
中注册片段com.acme.search.SearchExtension=com.acme.search.DefaultSearchExtension
现在您就可以使用您的扩展了;只需将接口添加到您的仓库中。
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
来实现,如下示例所示
-
Java
-
XML
@Configuration
@EnableJpaRepositories(repositoryBaseClass = MyRepositoryImpl.class)
class ApplicationConfiguration { … }
<repositories base-package="com.acme.repository"
base-class="….MyRepositoryImpl" />