springboot2.3 整合mybatis-plus 高级功能(图文详解)

    学习并使用mybatis-plus的一些高级功能的用法例如: AR模式、 乐观锁 、逻辑删除 、自动填充、数据保护等功能

    为了方便演示,咱们还是新建一个全新的项目

    image-20200806214645476

    引入mp依赖

    
    <dependency>
     <groupId>com.baomidou</groupId>
     <artifactId>mybatis-plus-boot-starter</artifactId>
     <version>3.3.2</version>
     </dependency>

    yml配置

    
    # 配置端口
    server:
     port: 8080
    spring:
     # 配置数据源
     datasource:
     driver-class-name: com.mysql.cj.jdbc.Driver
     url: jdbc:mysql://localhost:3306/mybatis-plus?serverTimezone=UTC&useUnicode=true&characterEncoding=utf-8
     username: root
     password: root
    
    # mybatis-plus相关配置
    mybatis-plus:
     # 以下配置均有默认值,可以不设置
     global-config:
     db-config:
     #主键类型 auto:"数据库ID自增"
     id-type: auto
     configuration:
     # 是否开启自动驼峰命名规则映射:从数据库列名到Java属性驼峰命名的类似映射
     map-underscore-to-camel-case: true
     # 如果查询结果中包含空值的列,则 MyBatis 在映射的时候,不会映射这个字段
     call-setters-on-nulls: true
     # 这个配置会将执行的sql打印出来,在开发或测试的时候可以用
     log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

    在 Spring Boot 启动类中添加 @MapperScan 注解,扫描 Mapper 文件夹

    image-20200806215534085

    (一)AR模式使用

    ActiveRecord模式:支持 ActiveRecord 形式调用,实体类只需继承 Model 类即可进行强大的 CRUD 操作

    即直接使用实体类 CRUD操作

    1.继承Model

    image-20200806221012349

    点进Model 类中 ,发现其提供了一些基础的CRUD操作方法,并实现了序列化接口

    image-20200806220842130

    注意的是,如果要使用ActiveRecord模式,仅仅继承Model 是不行的,这一点官网没有很显示的提到,还需要编写mapper接口 继承BaseMapper接口,泛型为当前实体类

    2.mapper接口

    如果不编写Mapper直接使用Model方法会报错:

    image-20200806221302376

    那么,咱们来编写mapper

    image-20200806221326120

    再次测试

    3.CRUD操作

    新增操作

    image-20200806221413677

    查询操作

    image-20200806221705933

    修改操作

    image-20200806221825358

    删除操作

    image-20200806221936204

    此AR模式呢,可以在开发中减少我们很多的调用代码,简单操作无需额外使用Mapper、service调用

    (二)乐观锁

    使用Mybatis-plus实现乐观锁

    乐观锁:总是假设最好的情况,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,乐观锁适用于多读的应用类型,这样可以提高吞吐量。

    mybatis-plus 提供的乐观锁 是采用了版本号机制

    数据表中加上一个数据版本号version字段,表示数据被修改的次数,当数据被修改时,version值会加一。当线程A要更新数据值时,在读取数据的同时也会读取version值,在提交更新时,若刚才读取到的version值为当前数据库中的version值相等时才更新,否则重试更新操作,直到更新成功。

    mp项目使用乐观锁是使用其插件配置–配置Bean的形式

    1.bean配置

    
    @Bean
    public OptimisticLockerInterceptor optimisticLockerInterceptor() {
     return new OptimisticLockerInterceptor();
    }

    image-20200806222513767

    2.实体类以及数据库添加对应字段以及列

    
    @Version
    private Integer version;

    image-20200806222639173

    image-20200806222908272

    至于version初始值,可以数据库默认设置为0,也可以再新增数据时手动设置verion版本号,个人是采用了数据库默认值

    那么我们在做任何查询修改删除的时候呢,mp会默认帮我们吧版本号作为条件带上,判断与数据库中该数据版本号是否一致。

    3.相关操作以及注意事项

    首先插入一条数据

    image-20200806223134584

    image-20200806223150227

    查询并修改该条信息

    发现其在修改的时候,将version作为了条件,并对version做了修改 set操作(默认是在原基础上+1)

    image-20200806224245623

    image-20200806224258714

    需要注意的几个点:

    支持的数据类型只有:int,Integer,long,Long,Date,Timestamp,LocalDateTime
    整数类型下 newVersion = oldVersion + 1
    newVersion 会回写到 entity 中
    仅支持 updateById(id) 与 update(entity, wrapper) 方法
    在 update(entity, wrapper) 方法下, wrapper 不能复用!!!

    什么意思呢,就是要想使用乐观说,首先 类型有限制,其次,修改方法仅仅只有上方两个有效,才会在修改时候对版本号就行修改操作 以及 要想版本号升级必须 是要把之前版本号传过去。

    即version操作时,我必须把旧的带过去

    版本号不对,是无法进行数据更新操作的(删除、修改)

    image-20200806224911876

    而如果不传递版本号的话,那么该字段就不会被维护了(失去了乐观锁 版本号机制 的意义了)

    image-20200806225056838

    版本号回传 修改正确 版本号维护成功

    image-20200806225332135

    如此,就实现了乐观锁了,mp基础上使用乐观锁,就是这么简单

    (三)逻辑删除

    物理删除:将数据库中该信息进行彻底删除,无法恢复。 应的SQL语句:delete from 表名 where 条件

    逻辑删除:逻辑删除的本质是修改操作,所谓的逻辑删除其实并不是真正的删除,而是在表中将对应的是否删除标识,然后修改 查询操作时将 是否删除标识字段作为条件带上,进而达到逻辑上删除了数据,但实际仍然保留了数据(尽管此数据在逻辑中不会再使用了)

    例如:自己设置一个逻辑删除字段,例如1表示数据有效,0表示被删除即可,默认是1

    Mybatis-plus 已经为我们提供了逻辑删除封装

    只对自动注入的sql起效:

    插入: 不作限制
    查找: 追加where条件过滤掉已删除数据,且使用 wrapper.entity 生成的where条件会忽略该字段
    更新: 追加where条件防止更新到已删除数据,且使用 wrapper.entity 生成的where条件会忽略该字段
    删除: 转变为 更新
    例如:

    删除: update user set deleted=1 where id = 1 and deleted=0
    查找: select id,name,deleted from user where deleted=0
    字段类型支持说明:

    支持所有数据类型(推荐使用 Integer,Boolean,LocalDateTime)
    如果数据库字段使用datetime,逻辑未删除值和已删除值支持配置为字符串null,另一个值支持配置为函数来获取值如now()
    附录:

    逻辑删除是为了方便数据恢复和保护数据本身价值等等的一种方案,但实际就是删除。
    如果你需要频繁查出来看就不应使用逻辑删除,而是以一个状态去表示。

    使用步骤:

    1.数据库添加字段

    对某个表的数据需要使用逻辑删除,则必须创建逻辑删除字段

    image-20200808110331856

    2.mp逻辑删除配置

    在原有的mp配置上 添加逻辑删除设置

    其已删除 未删除值均有默认值 1 0 如果你预想设置值与之一致,仅仅编写 逻辑删除字段名即可

    image-20200808110905817

    3.实体类加逻辑删除字段以及注解

    image-20200808111149966

    mp中 逻辑删除相关配置就没了 ,很是简单————咱们开始测试

    咱们先删除数据库中原有数据

    image-20200808111441145

    可以看到 ,删除语句实际上是执行了update(修改) 额外将 我们设置好的逻辑删除字段值作为条件(未删除 0),并修改 值为1(已删除)

    image-20200808111531657

    接下来,我们来进行查询操作,看是否还能取出数据

    total=0 ,没有数据, 那么我们便做到了业务意义上的数据删除(逻辑删除)

    image-20200808111933875

    其只要是设置了逻辑删除 ,修改 删除 查询操作均会携带上未删除条件 ,保证操作的数据时 “存在” 的()

    (四)自动填充

    在开发中哈,我们一个表的字段除了业务字段外,实际上还会添加维护字段 ,即 创建人 创建时间 修改人 修改时间 ,让数据的操作 有迹可循,方便管理

    如下:

    image-20200808112656976

    实体类添加维护字段信息

    image-20200808112809346

    那么每次在操作数据的时候需要我们手动插入到该model中 进行保存,再操作数据

    例如添加时

    image-20200808113226978

    image-20200808113243561

    例如修改时

    image-20200808113539478

    image-20200808113559081

    这样呢,每次我们在操作数据时都需要在业务代码中编写 新增用户ID 当前时间 修改用户ID 修改时间等字段等,就比较繁琐

    项目很大,几百个Model 乘以Four 那么就额外编写几千行代码进行维护了

    解决办法:

    1.自定义Aop 进行数据填充

    2.使用现成的 (mp都用了,用他的自动填充不香吗)

    操作开始:

    1.自定义实现类 MyMetaObjectHandler

    这里需要注意哈

    这二者呢,一个是插入的类型 一个是插入的值 必须对应上,或者 自动填充时会报错

    image-20200808114936751

    
    @Slf4j
    @Component
    public class MyMetaObjectHandler implements MetaObjectHandler {
    
     @Override
     public void insertFill(MetaObject metaObject) {
     log.info("start insert fill ....");
     this.strictInsertFill(metaObject, "createTime", Long.class, System.currentTimeMillis());
     //开发中 创建者 修改者ID 通过Aop 或者权限框架获取当前操作用户 ,用用户ID进行填充即可
     this.strictInsertFill(metaObject, "createId", Long.class, 666L);
    
     }
    
     @Override
     public void updateFill(MetaObject metaObject) {
     log.info("start update fill ....");
     this.strictUpdateFill(metaObject, "modifyTime", Long.class, System.currentTimeMillis());
     this.strictUpdateFill(metaObject, "modifyId", Long.class, 666L);
    
     }
    }

    2.实体类注解

    要开启自动填充功能 实现 MetaObjectHandler 还不行,因为Mp 啊,对其字段默认是不做处理的,所以,咱们配置了 新增修改 自动填充时 还需要在其字段上进行开启

    
    @TableField(fill = FieldFill.INSERT)

    image-20200808114731349

    image-20200808114705528

    OK。设置好了,咱们插入修改试一试吧!

    image-20200808115231603

    image-20200808115251910修改

    image-20200808115517443

    image-20200808115528774

    如此 mp的自动填充就可以了,根据业务 合理对默写字段填充,填充什么值 自己考量即可

    但是呢,也是有一定问题的

    比如:我有一个定时维护功能,是由xxl-job发起的定时任务,那么这个时候,我字段维护信息,为了区分开到底是认为维护还是自动维护,那么就需要手动设置 创建修改人 以及时间了

    这个时候呢,自动填充功能会把我们自己设置的进行覆盖

    所以呢,自动填充咱们也可以进行优化,当有该维护字段时,且字段无值时才填充,当无维护字段或者 维护字段设置了值则不填充

    3.自动填充优化

    实际就是做了判断 判断该字段是否有set属性 有则尝试填充 (无值则填充)

    
    @Slf4j
    @Component
    public class MyMetaObjectHandler implements MetaObjectHandler {
    
     @Override
     public void insertFill(MetaObject metaObject) {
     //判断是否有set属性
     if (metaObject.hasSetter("createId")) {
      //判断是否有值 如果没设置值 则为null
      Object createId = getFieldValByName("createId", metaObject);
      if (createId == null) {
      log.info("创建人需要维护 且值为空 需要填充 ");
      //开发中 创建者 修改者ID 通过Aop 或者权限框架获取当前操作用户 ,用用户ID进行填充即可
      this.strictInsertFill(metaObject, "createId", Long.class, 666L);
    
      }
     }
     if (metaObject.hasSetter("createTime")) {
      Object createTime = getFieldValByName("createTime", metaObject);
      if (createTime == null) {
      log.info("创建时间需要维护 且值为空 需要填充 ");
      this.strictInsertFill(metaObject, "createTime", Long.class, System.currentTimeMillis());
      }
     }
    
     }
    
     @Override
     public void updateFill(MetaObject metaObject) {
     if (metaObject.hasSetter("modifyId")) {
      Object modifyId = getFieldValByName("modifyId", metaObject);
      if (modifyId == null) {
      log.info("修改人需要维护 且值为空 需要填充 ");
      this.strictUpdateFill(metaObject, "modifyId", Long.class, 666L);
      }
     }
     if (metaObject.hasSetter("modifyTime")) {
      Object modifyTime = getFieldValByName("modifyTime", metaObject);
      if (modifyTime == null) {
      log.info("修改时间需要维护 且值为空 需要填充 ");
      this.strictUpdateFill(metaObject, "modifyTime", Long.class, System.currentTimeMillis());
      }
     }
    
     }
    }

    测试:

    我这里设置了创建者ID ,虽然createId需要维护,但我们设置了值 则不会进行填充了,修改亦是如此!

    image-20200808124200342

    image-20200808124331978

    那么自动填充功能,就完了,整合时 结合项目,适当修改即可。

    (五)数据保护

    使用mp中的加密方式,对配置文件中一些敏感信息进行加密(例如密码)

    其和 Jasypt 项目加密方式类似

    1.生成随机秘钥以及内容加密

    image-20200808154301136

    image-20200808154406180

    2.配置文件替换

    我们将原本的明文信息(root)换成加密后的密文信息

    格式:

    mpw:xxxx密文信息

    image-20200808154539290

    3.设置密钥到启动参数中

    idea 设置方式:

    image-20200808154642114

    image-20200808154702402

    启动测试–获取到了数据 证明数据库连接成功,其加密内容在连接时也被密钥解密了,但配置中,无明文信息,一定程度保护了项目

    image-20200808154741030

    jar 启动时 设置密钥参数:

    image-20200808155350475

    项目地址:springboot-mp进阶

    到此这篇关于springboot2.3 整合mybatis-plus 高级功能的文章就介绍到这了,更多相关springboot2.3 整合mybatis-plus内容请搜索lingkb以前的文章或继续浏览下面的相关文章希望大家以后多多支持lingkb!