快速学习一个新框架最好的办法一定是查看官方文档，如果有较好的视频另说
警惕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 层的业务逻辑代码里，很少能复用
