快速学习一个新框架最好的办法一定是查看官方文档,如果有较好的视频另说
警惕CSDN上面的一些垃圾文章,大部分都是抄的官方文档,还没抄全
详细用法官方文档都有,这里只是记录一下自己用的过程中的小细节
ps:以下所有都还停留在使用层面
MyBatis-Flex 是什么
MyBatis-Flex 是一个优雅的 MyBatis 增强框架,它非常轻量、同时拥有极高的性能与灵活性。我们可以轻松的使用 Mybaits-Flex 链接任何数据库,其内置的 QueryWrapper
帮助我们极大的减少了 SQL 编写的工作的同时,减少出错的可能性。
总而言之,MyBatis-Flex 能够极大地提高我们的开发效率和开发体验,让我们有更多的时间专注于自己的事情。
这是引用的官方的一段话,关注以下几点信息:
- 基于
mybatis
,主要是这玩意在国内太广泛了,什么?你不知道这个,那哥们就先别看了,还得练练
反正mybatis
都学了,大概率也学了mq
,那就来学学flex
吧,反正不要钱主要是公司要用,不然都没听说过 QueryWrapper
其实就是用来构建自定义SQL语句的类,比起写xml的确好很多
MyBatis-Flex 和同类框架对比
官网有。。。
之所以有这个标题是想吐槽一下,妈的关于flex
的文章,10个里9个都贴了官网的那张长图 好奇就自己去瞅瞅
一看到这玩意,我就知道这篇文章又是CV的官方文档,所以一定要学会看官方文档
但官方文档可以看出,flex
对标的是目前市场主流的mq
,野心很大
给我碾死mq
这垃圾,我要看血流成河
个人感觉的亮点
关联查询 Relations
注解
真正的业务里,就没有一个功能是查一张表就能解决的。
mq
与mybatis
的关联查询很难满足要求
flex
的关联查询用多了是真的爽,一开始注解好了之后就能愉快的查询了
特别是一对一,一对多之类的设计基本上覆盖了需求
QueryWrapper
的自定义查询语句
当初用mq
时,它的快捷单表查询让我非常轻松,感觉很爽
可惜真正业务里,非常鸡肋,虽然mq
也能自定义查询语句,但那个工具类。。。一言难尽
QueryWrapper
的自定义语句非常接近原生的SQL语句,熟悉便有了安全感
QueryWrapper query = new QueryWrapper()
.select(
ACCOUNT.ID
, ACCOUNT.USER_NAME
, ARTICLE.ID.as("articleId")
, ARTICLE.TITLE)
.from(ACCOUNT.as("a"), ARTICLE.as("b"))
.where(ACCOUNT.ID.eq(ARTICLE.ACCOUNT_ID));
非常接近原生SQL
发现的小细节
RelationManage
内部是用的ThreadLocal
当初还在想指定关联查询字段,在清除之前会不会有并发时污染查询字段
结果点开源码一看,基本上都是ThreadLocal
关联嵌套
这个词是我编的
如果说A里面关联了B,B里面关联了C,甚至说C里面还关联了A 俄罗斯套娃呀
在关联查询中,我发现最多查出三层关联
如果是指定了查询字段,除非刚好名字一样,否则就不会出现嵌套查询
自动判空
在用QueryWrapper
时,在构建条件时,仿佛flex
会自动判断你传入的数据是否为空
为空的话,这个条件语句就不会再SQL里出现
QueryWrapper query = new QueryWrapper()
.select(ACCOUNT.ALL_COLUMNS)
.from(ACCOUNT)
.where(ACCOUNT.ID.eq(id));
正常SQL为
select * from account where id = ?
如果是id
字段为null
的话
select * from account
个人感觉的小坑
常见的查询里,查出来的都是整个类
哪怕你只是查询了一个字段,都会给你包装成整个类
特别是里面还有大量关联的类
虽然这年头基本上不咋管空间问题,但这也太浪费空间了吧
关联混乱
如果一开始没制定好详细的开发规范的话,在基本类里面随意添加关联字段的话
最后会显得很乱很乱
关联嵌套时的数据格式校验
如果说,你数据库的字段与你实体类上面的声明对不上,或者说格式对不上,肯定报错
这也还好排查
但如果是关联好的类里面的字段对不上的话,那就不好查了,虽然最深三层,但鬼知道关联了多少类
一查一个不吱声
所以还是老老实实指定字段查询吧
RelationManager.addQueryRelations("books","roles");
List<Account> accounts = accountMapper.selectAllWithRelations();
像这样
mapper
层的复用太少
准确来说这不是flex
的问题,而是程序员的问题
在使用mapper
类的时候,基本上都倾向于直接使用QueryWrapper
直接构建查询语句
这样这些语句大量集中在service
层的业务逻辑代码里,很少能复用