关于微服务:微服务开发系列数据库-orm-使用

零碎中应用 mybatis plus 框架作为关系型数据库的 orm 框架。

1 mybatis plus 应用

1.1 不应用 IService

mp 应用提供了一个 IService 类，作为业务层的扩大。

然而框架中不倡议这种将业务代码和根底性能混合的做法，这会导致业务的灵活性降落，耦合度过高。

在我了解的 spring boot 设计中，偏向于让开发人员的业务代码尽量扁平化，不同类型的性能，更加倡议你应用多个类的形式，而后通过注入这个类获取不同类型的性能。

因而同样的 controller 层也不倡议应用继承来减少额定的性能。

为了补充一些 IService 的性能，框架中提供了 PBaseMapper 来加强 BaseMapper。

本人做加强类的益处之一就是灵便。

PBaseMapper 还提供了一个 ktUpdate 的办法，返回了通过 Enhancer 代理的 KtUpdateChainWrapper 变量。

它的作用是当应用 set办法时，判断一个字段是否有 TableField 注解，如果有则主动批改 mapper 参数，减少 typeHandler 配置，来避免 mybatis plus 在更新时传递给 ibatis 的简单对象序列化失败的问题（详情见 issue）。

1.2 配置加强

对于 mybatis plus，框架中做了对立的配置加强，门路在 business-foundation:cn.business.foundation.config.mybatis 中。

上面对这几个类进行阐明。

1.2.1 BaseEntity

根底实体类，蕴含如下的字段。

根底实体类不要求强制继承，能够本人抉择。

1.2.2 MetaObjectHandlerConfig

主动装载类，配置审计性能，当实体类蕴含上述四个字段时，会做相应的字段填充。

1.2.3 MybatisPlusConfig

主动状态类，配置与 mybatis plus 相干的拦截器或者其它配置。

1.2.4 PBaseMapper

BaseMapper 的加强实现，代替 mybatis plus 提供的 com.baomidou.mybatisplus.extension.service.IService，IService 本来是用于继承给业务中的 Service 层应用，加强数据库的能力，然而在这里认为，Service 层不适宜继承这种类型的类。

1.3 jpa like 能力

mybatis plus 基于 mybatis 做的性能强化，可能在单表简略操作上可能达到与 jpa 十分靠近的程度。

也就是说，如果正当的使用 mybatis plus 提供的扩大能力，在切换数据库时，可能无效的升高迁徙老本，比方上面这段代码。

User user = userMapper.lambdaQuery()
    .select(User::getPassword)
    .eq(User::getAccount, account)
    .oneOpt()
    .orElseThrow(() -> {log.warn("account not found {}", account);
        return new InnerExp("用户名或明码谬误");
    });

在代码中没有应用任何的 sql 即可实现查问，然而这种操作仅限于单表操作，简单的多表查问必须用到 xml 写 sql。

在下面查问中，请留神到 User::getAccount 这样的用法，在代码中尽量避免间接应用常量字符串，这样你在批改某个字段的名称时，就可能利用古代 IDE 提供的批改能力，将所用援用对立批改。

例如当你心愿获取到 account 时，能够应用 User::getAccount.name。

2 分页

2.1 PageParam

门路 cn.business.foundation.common.page.PageParam。

用于接管前端的分页和排序参数，在接收数据时能够应用这种形式接管，把分页参数和其它参数分成两个变量接管，这样就不必在每个你要接管的变量上再继承一个分页类，这样可能更加的灵便。

    @GetMapping("/query")
    public RequestResult selectUsers(PageParam pageParam, UserDTO userDTO) {return userService.selectUsers(pageParam, userDTO);
    }

PageParam 还应该提供了转化成查问所需的分页对象，比方框架中的 PageParam 就提供了 mybatis-plus 的分页对象，后续如果还有其它类型的查问，比方 elasticsearch 查问，也应该在这里提供相应的分页对象，这样就能做到分页参数的对立的。

在分页中能够看出，绝大部分类型的查问，参数上理论只有三类：

1. 页数与条数
2. 排序列
3. 排序方向

齐全能够应用一个类来代替，spring data 实际上就提供了一个十分好的范例，jpa 与 elasticsearch 等其余 data 架构上面的实现，都是根据这个范例来做到对立的，这个思维同样也能扩大到其它须要分页的查问。

还应该留神到，在包 cn.vte.business.foundation.common.page 下，提供了一个文件 MybatisPlusPage，提供了 PageParam 到 mybatis plus page 的 转换扩大函数。

如果将其写入到 PageParam 中，有些模块在没有依赖 mybatis plus 的状况下，会导致 mybatis plus page 的相干类找不到。

雷同的思路同样实用于 elasticsearch。

这也是 kotlin 扩大函数带来的设计上的长处。

2.2 PageResult

门路 cn.business.foundation.common.page.PageResult。

有分页参数就有分页后果，这个类就是用于返回分页后果的。设置为 RequestResult 的 value 即可。

与 2.1 中应用的思维一样，实用于分页的返回后果，都应该在这个类中转化一遍，不便对立输入。

如果波及到其它数据库的类型转换，做法相似于 cn.vte.business.foundation.common.page.MybatisPlusPage，应用扩大的形式提供新的类型转换形式，防止出现 ClassNotFoundException 异样。

3 mapper xml 文件地位

在框架中，要求 mapper xml 与实例类文件搁置在一起。在一些我的项目中经常见到 xml 是放在 resources 上面的，这样我感觉跳转起来，会导致目录较乱，所以这里把 java 和 xml 放在一起，开发起来不便一点。

拷贝 xml 文件到编译地位的配置在 server:build.gradle.kts 中。