弃用

在对开发流程的进一步学习后，本人认为下面的扩展并不见得是一个很好的做法。不应该使用过多的关联，过多的关联会导致笛卡尔积的膨胀，导致查询效率降低。

• 可以考虑先查询出 A 表对象，拷贝到 AVo 对象，再使用 in 查询 B 对象，再组装到 AVo 中。
• 在必须多联表查询的场景中，可以考虑使用视图。

扩展初衷

MP 的条件构造器能让我在开发中不必在 XML 中编写大量的非空判断，使得常用的 CRUD 功能变得高效。但有这么一种场景，MP 似乎不支持：

假设我现在有一张学生表 student ，我需要返回给前端时携带 班级名称 字段，而 student 表中只有 clazz_id 字段，需要关联班级表 clazz 获取，查询条件还是 student 表的字段，但 MP 并不能很好的处理这件事情。

<select id="selectListStudentVO" resultType="cn.nipx.school.vo.StudentVO">
    SELECT s.*,c.name AS clazz_name
    FROM student AS s
    INNER JOIN clazz AS c ON s.clazz_id = c.id
    ${ew.customSqlSegment}
</select>

由 MyBatis-Plus - 使用 Wrapper 自定义 SQL (opens new window) 可知：

使用 ${ew.customSqlSegment} 不支持 Wrapper 内的 entity 生成 where 语句

因此在 Service 层中不能再使用以下写法

// controller传递查询条件studentVO
LambdaQueryWrapper<StudentVO> queryWrapper = new LambdaQueryWrapper<>(studentVO);
return this.list(queryWrapper);

而是需要手动构建 Wrapper

LambdaQueryWrapper<StudentVO> queryWrapper = new LambdaQueryWrapper<>();
queryWrapper.eq(StudentVO::getName, studentVO.getName());
queryWrapper.eq(StudentVO::getClazzId, studentVO.getClazzId());
return this.list(queryWrapper);

而这样又有另一个问题了，因为 name 字段在 student 表和 clazz 表都有，而生成的 sql 中条件 name 是没有加别名的，MySQL 也就不知道 name 指的是哪个，从而报错。

环境

todo