SpringDataJPA让一切近乎完美
SpringDataJPA主要针对的是Spring唯一没有简化到的业务逻辑的代码,连开发者仅剩的持久层的业务逻辑的工作都省了。唯一要做的就是申明持久层的接口,其他的都交给SpringDataJPA来解决,比如增删改查等方法。
也就是说,当你看到UserRepository.getUserByUserName(),很明显你就能知道这个方式是通过UserName来得到一条User的数据。
SpringDataJPA要做的就是规范DAO层接口的方法名字,根据符合规范的名字来确定实现什么样的逻辑,用户不需要写“@Query(value = “”)”的sql语句,也能操作数据库。
下面就来详细看一下关于SpringDataJPA的神奇:
1.SpringDataJPA简介
(1)JPA:它主要是为了整个第三方ORM框架,建立一种标准的方式。
* ORM框架:提供持久化类和表的映射关系
* ORM框架中改,hibernate,iBATs,mybits,EclipseLink
* JPA和hibernate整合良好,可以认为JPA是标准,它有很多借口提供为第三方框架的整合,它只是单纯的提供接口,而实际的事情是由hibernate来完成的。
(2)SpringDataJPA又是什么?
Spring整合第三方框架的能力很强,它所起的作用不单单体现在最初的IOC容器上,现在Spring设计的方面很广,主要体现在对第三方的整合上。
SpringDataJPA就是针对一些关系型数据库,采用统一技术进行访问,并且尽量简化访问手段。
2.为什么使用SpringDataJPA?
(1)它带来的好处:
Spring Data Jpa 极大简化了数据库访问层代码,只要3步,就能搞定一切
* 编写Entity类,依照JPA规范,定义实体
* 编写Repository接口,依靠SpringData规范,定义数据访问接口(注意,只要接口,不需要任何实现)
* 写一小陀配置文件 (Spring Scheme配置方式极大地简化了配置方式)
(2)众所周知,我们在使用持久化工具的时候,一般都有一个对象来操作数据库,如hibernate中的session。Spring分为三层来讲,service是业务逻辑层,DAO层主要负责和数据库打交道,这里的DAO层就包含SpringDataJPA这样一个对象。
ORM框架本身提供有CURD方法,但是在DAO的业务逻辑实现的过程中并没有提供,开发者需要自己手动写sql语句,再对数据库进行操作。这时候,SpringDataJPA就派上用场了。它提供了ORM框架提供的DAO层功能,也提供了ORM不提供的DAO层业务逻辑功能。全方位的解决开发者的苦恼。
使用SpringDataJPA,开发人员是很少写sql语句的,除非很特殊很特殊的方法,不能按照规则表达出来的方法名臣时,才需要使用sql语句来精确定义属性和获取值。
SpringDataJPA会根据方法的名字自动生成sql语句
3.配置
(1)DAO:data Access Object
(2)实体管理器:
<property name = "packagesToScan" value = "your entity package">
用来加载我们的Entity
4.关于实现的接口
(1)Repository:SpringDataJPA的和新街口,是一个标记型接口,表示任何继承它的接口都是仓库接口类;
(2)CrudRepository:包含10种CRUD的方法;
(3)PagingAndSortingRepository:包含10种CRUD的方法外,多了“分页和排序”;
(4)JpaRepository:比起(3)多了“其他的一些常用方法”
那么很显然了,他们的父子类关系如下:
Repository———–>CrudRepository———>PagingAndSortingRepository————>JpaRepository
5.SpringDataJPA自定义的查询方法 定义规范
And 并且
Or 或
Is,Equals 等于
Between 两者之间
LessThan 小于
LessThanEqual 小于等于
GreaterThan 大于
GreaterThanEqual 大于等于
After 之后(时间) >
Before 之前(时间) <
IsNull 等于Null
IsNotNull,NotNull 不等于Null
Like 模糊查询。查询件中需要自己加 %
NotLike 不在模糊范围内。查询件中需要自己加 %
StartingWith 以某开头
EndingWith 以某结束
Containing 包含某
OrderBy 排序
Not 不等于
In 某范围内
NotIn 某范围外
True 真
False 假
IgnoreCase 忽略大小写
Spring Data JPA框架在进行方法名解析时,会先把方法名多余的前缀截取掉,比如 find、findBy、read、readBy、get、getBy,然后对剩下部分进行解析。
假如创建如下的查询:findByUserDepUuid(),框架在解析该方法时,首先剔除 findBy,然后对剩下的属性进行解析,假设查询实体为Doc
* 先判断 userDepUuid (根据 POJO 规范,首字母变为小写)是否为查询实体的一个属性,如果是,则表示根据该属性进行查询;如果没有该属性,继续第二步;
* 从右往左截取第一个大写字母开头的字符串此处为Uuid),然后检查剩下的字符串是否为查询实体的一个属性,如果是,则表示根据该属性进行查询;如果没有该属性,则重复第二步,继续从右往左截取;最后假设user为查询实体的一个属性;
* 接着处理剩下部分(DepUuid),先判断 user 所对应的类型是否有depUuid属性,如果有,则表示该方法最终是根据 “ Doc.user.depUuid” 的取值进行查询;否则继续按照步骤 2 的规则从右往左截取,最终表示根据 “Doc.user.dep.uuid” 的值进行查询。
* 可能会存在一种特殊情况,比如 Doc包含一个 user 的属性,也有一个 userDep 属性,此时会存在混淆。可以明确在属性之间加上 “_” 以显式表达意图,比如 “findByUser_DepUuid()” 或者 “findByUserDep_uuid()”