public class ArticleDTO {
private Long id;
private Long accountId;
private String title;
private String content;
//以下用户相关字段
private String userName;
private int age;
private Date birthday;
}
public class ArticleDTO {
private Long id;
private Long accountId;
private String title;
private String content;
//以下用户字段 和 用户表定义的列不一致,表定义的列为 user_name
private String authorName;
private int authorAge;
private Date birthday;
}
MyBatis 多表查询应该这么玩,MyBatis-Flex v1.3.3 发布
MyBatis-Flex v1.3.3 主要是增强了多表查询的功能,假设有
tb_account
用户表和tb_article
文章表,他们的字段分别如下:MyBatis-Flex 提供了 3 中方式,可以进行关联查询:
方式 1
1、定义
ArticleDTO
类,ArticleDTO
里定义tb_account
表的字段映射。然后直接通过 QueryWrapper 查询,代码如下:
方式 2
假设
ArticleDTO
定义的属性和 数据库字段不一致时,例如:那么,
QueryWrapper
需要添加as
,修改如下:方式 3
1、在
ArticleDTO
直接定义Account
实体类属性。 例如:查询方式和方式1一样,使用
QueryWrapper
构建left join
查询,查询结果通过ArticleDTO
类型接收。一对多查询
在以上的例子中,一个作者可能有多篇文档,假设 Account 的属性定义如下:
那么,查询代码如下:
知识点
MyBatis-Flex 的关联子查询,和 JPA 等其他第三方框架有很大的差异,比如 JPA 是通过配置来构建查询 SQL,其构建生成的 SQL 对于用户来说是不透明的。 因此,用户几乎无法对 JPA 的注解生成 SQL 优化。
而 MyBatis-Flex 关联子查询的 SQL 完全是由用户构建的,因此会更加灵活,更加有利于我们进行 SQL 优化。在子查询中,有很多的场景,JPA 一对一、 一对多等等不同的场景给出了不同的注解、以及参数,导致用户的学习成本非常高。另外,在很多业务场景下, 比如多租户、逻辑删除、等等 MyBatis-Flex 都是内部自动处理,而 JPA 通过注解的实现则是非常麻烦。
对 MyBatis-Flex 来说,学习成本是非常低的,在构建子查询时,只需要明白为哪个字段、通过什么样的 SQL 查询就可以了,以下是示例:
因此,在 MyBatis-Flex 的设计中,无论是一对多、多对一、多对多... 还是其他任何一种场景,其逻辑都是一样的。更多的文档请参考:https://mybatis-flex.com/zh/base/field-query.html
MyBatis-Flex v1.3.3 更新如下:
进一步了解 MyBatis-Flex 框架,请参考一下链接:
和其他框架对比请参考:
MyBatis-Plus
、Fluent-Mybatis
【功能】方面的对比:https://mybatis-flex.com/zh/intro/comparison.htmlMyBatis-Plus
【性能】方面的对比:https://mybatis-flex.com/zh/intro/benchmark.html感谢大家关注 MyBatis-Flex ,让我们一起携手,打造新一代的 MyBatis 增强框架。