【Spring连载】使用Spring Data的Repositories----定义Repository接口

2024-02-27 14:04

本文主要是介绍【Spring连载】使用Spring Data的Repositories----定义Repository接口,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

【Spring连载】使用Spring Data的Repositories----定义Repository接口

  • 一、微调Repository定义
  • 二、使用多个Spring Data模块的Repositories

要定义repository接口,首先需要定义特定于域(domain)类的repository接口。接口必须继承Repository,并且类型为域类和ID类型。如果你想公开该域类型的CRUD方法,可以继承CrudRepository或其变体之一,而不是Repository。

一、微调Repository定义

有几种变体可以帮助你开始使用repository接口。
典型的方法是继承CrudRepository,它为你提供了CRUD功能的方法。CRUD代表创建、读取、更新、删除。在3.0版本中,框架还引入了ListCrudRepository,它与CrudRepository非常相似,但对于那些返回多个实体的方法,它返回的是List,而不是Iterable,你可能会发现它更容易使用。
如果你使用的是反应式(reactive )存储,根据你使用的反应式框架,你可以选择ReactiveCrudRepository或RxJava3CrudRepository。
如果你正在使用Kotlin,您可以选择利用Kotlin协程的CoroutineCrudRepository。
此外,如果你需要允许指定排序抽象的方法,或者在第一种情况下是可分页抽象,则可以继承PagingAndSortingRepository、ReactiveSortingRepository、RxJava3SortingRepository或CoroutineSortingRepository。请注意,各种排序存储库不再像在Spring Data Versions 3.0之前那样扩展各自的CRUD repository。因此,如果您想要两个接口的功能,就需要继承这两个接口。
如果你不想继承Spring Data接口,也可以使用@RepositoryDefinition注解repository接口。继承其中一个CRUD存储库接口将公开一整套操作实体的方法。如果你希望对公开的方法有选择性,请将要公开的方法从CRUD repository复制到你的域repository中。这样做时,你可以更改方法的返回类型。如果可能的话,Spring Data将采用返回类型。例如,对于返回多个实体的方法,你可以选择Iterable, List, Collection或VAVR列表。
如果应用程序中的许多存储库应该具有相同的方法集,则可以定义自己的基本接口以从中继承。这样的接口必须用@NoRepositoryBean进行注解。这防止了Spring Data尝试直接创建它的实例导致失败,因为它无法确定该存储库的实体,因为它仍然包含一个泛型类型变量。
以下示例展示了如何选择性地公开CRUD方法(在本例中为findById和save):
选择性地公开CRUD方法

@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查找单个用户,并触发查询以通过电子邮件地址查找用户。
中间(intermediate)存储库接口用@NoRepositoryBean进行注释。确保将该注解添加到所有不需要Spring Data在运行时为其创建实例的存储库接口中。

二、使用多个Spring Data模块的Repositories

在应用程序中使用唯一的Spring Data模块使事情变得简单,因为定义的范围中的所有存储库接口都绑定到Spring Data模块。有时,应用程序需要使用多个Spring Data模块。在这种情况下,存储库定义必须区分持久化技术。当Spring Data在类路径上检测到多个存储库工厂时,它将进入严格的(strict )存储库配置模式。严格的配置使用存储库或域类的详细信息来决定存储库定义的Spring Data模块绑定:

  1. 如果存储库定义继承了特定于模块的存储库,则它是特定Spring Data模块的有效候选者。
  2. 如果域类使用特定于模块的类型注解进行注解,则它是特定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,它是用JPA@Entity注解的,所以这个存储库显然属于Spring Data JPA。UserRepository引用了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不能区分存储库,这导致了未定义的行为。
存储库类型详细信息(前述例1)和区分域类注解(前述例3)用于严格的(strict)存储库配置,以识别特定Spring Data模块的候选存储库。在同一域类型上使用多个特定于持久性技术的注解是可能的,并且可以跨多种持久性技术重用域类型。但是,Spring Data无法再确定用于绑定存储库的唯一模块。
区分存储库的最后一种方法是确定存储库基本包(base packages)的范围。基本包定义了扫描存储库接口定义的起点,这意味着存储库定义位于适当的包中。默认情况下,注解驱动的配置使用配置类的包。基于XML的配置中的基本包是必需的。
以下示例展示了基本包的注解驱动配置:
基本包的注解驱动配置

@EnableJpaRepositories(basePackages = "com.acme.repositories.jpa")
@EnableMongoRepositories(basePackages = "com.acme.repositories.mongo")
class Configuration {}

这篇关于【Spring连载】使用Spring Data的Repositories----定义Repository接口的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/752640

相关文章

JVM 的类初始化机制

前言 当你在 Java 程序中new对象时,有没有考虑过 JVM 是如何把静态的字节码(byte code)转化为运行时对象的呢,这个问题看似简单,但清楚的同学相信也不会太多,这篇文章首先介绍 JVM 类初始化的机制,然后给出几个易出错的实例来分析,帮助大家更好理解这个知识点。 JVM 将字节码转化为运行时对象分为三个阶段,分别是:loading 、Linking、initialization

Spring Security 基于表达式的权限控制

前言 spring security 3.0已经可以使用spring el表达式来控制授权,允许在表达式中使用复杂的布尔逻辑来控制访问的权限。 常见的表达式 Spring Security可用表达式对象的基类是SecurityExpressionRoot。 表达式描述hasRole([role])用户拥有制定的角色时返回true (Spring security默认会带有ROLE_前缀),去

浅析Spring Security认证过程

类图 为了方便理解Spring Security认证流程,特意画了如下的类图,包含相关的核心认证类 概述 核心验证器 AuthenticationManager 该对象提供了认证方法的入口,接收一个Authentiaton对象作为参数; public interface AuthenticationManager {Authentication authenticate(Authenti

Spring Security--Architecture Overview

1 核心组件 这一节主要介绍一些在Spring Security中常见且核心的Java类,它们之间的依赖,构建起了整个框架。想要理解整个架构,最起码得对这些类眼熟。 1.1 SecurityContextHolder SecurityContextHolder用于存储安全上下文(security context)的信息。当前操作的用户是谁,该用户是否已经被认证,他拥有哪些角色权限…这些都被保

Spring Security基于数据库验证流程详解

Spring Security 校验流程图 相关解释说明(认真看哦) AbstractAuthenticationProcessingFilter 抽象类 /*** 调用 #requiresAuthentication(HttpServletRequest, HttpServletResponse) 决定是否需要进行验证操作。* 如果需要验证,则会调用 #attemptAuthentica

Spring Security 从入门到进阶系列教程

Spring Security 入门系列 《保护 Web 应用的安全》 《Spring-Security-入门(一):登录与退出》 《Spring-Security-入门(二):基于数据库验证》 《Spring-Security-入门(三):密码加密》 《Spring-Security-入门(四):自定义-Filter》 《Spring-Security-入门(五):在 Sprin

Java架构师知识体认识

源码分析 常用设计模式 Proxy代理模式Factory工厂模式Singleton单例模式Delegate委派模式Strategy策略模式Prototype原型模式Template模板模式 Spring5 beans 接口实例化代理Bean操作 Context Ioc容器设计原理及高级特性Aop设计原理Factorybean与Beanfactory Transaction 声明式事物

中文分词jieba库的使用与实景应用(一)

知识星球:https://articles.zsxq.com/id_fxvgc803qmr2.html 目录 一.定义: 精确模式(默认模式): 全模式: 搜索引擎模式: paddle 模式(基于深度学习的分词模式): 二 自定义词典 三.文本解析   调整词出现的频率 四. 关键词提取 A. 基于TF-IDF算法的关键词提取 B. 基于TextRank算法的关键词提取

使用SecondaryNameNode恢复NameNode的数据

1)需求: NameNode进程挂了并且存储的数据也丢失了,如何恢复NameNode 此种方式恢复的数据可能存在小部分数据的丢失。 2)故障模拟 (1)kill -9 NameNode进程 [lytfly@hadoop102 current]$ kill -9 19886 (2)删除NameNode存储的数据(/opt/module/hadoop-3.1.4/data/tmp/dfs/na

Hadoop数据压缩使用介绍

一、压缩原则 (1)运算密集型的Job,少用压缩 (2)IO密集型的Job,多用压缩 二、压缩算法比较 三、压缩位置选择 四、压缩参数配置 1)为了支持多种压缩/解压缩算法,Hadoop引入了编码/解码器 2)要在Hadoop中启用压缩,可以配置如下参数