MyBatis-Plus 初步使用心得-连表分页查询的实现

MyBatis-plus 是基于mybatis的增强工具，是一款稳定强大的工具。

配置安装参考:https://mp.baomidou.com/guide/install.html#release

经过一段时间的初步使用 mybatis-plus 的核心功能 CRUD接口和 代码生成器都有所接触。
以下是一些心得，会逐步更新

CRUD接口的使用-连表分页查询

entity的创建

需要添加主键策略和字段验证策略，有待研究。

@TableName("athlete")//指定表名
public class AthleteBO{

	@TableId(type = IdType.AUTO)//指定主键
	private Long id;

	//非空判断,NOT_NULL / NOT_EMPTY / IGNORED / DEFAULT
	@TableField(strategy = FieldStrategy.NOT_NULL)
	private String name;

	private String unit_code;
	
	@TableField(exist = false)//冗余字段
	private String unit_name;

	//省略get set 方法和 toString
}

主键策略详情可以参考 https://blog.csdn.net/u010514052/article/details/81775595

Dao/Mapper 层 Service 层的建立

mybatis底层封装了 增删改查 分页 等很多方法，初步实现了增删改和普通的连表分页查询，下面主要以分页查询为例。
dao代码

@Repository
public interface IAthleteDao extends BaseMapper<AthleteBO> {

	//IPage 分页器， QueryWrapper 条件构造器
    IPage<AthleteBO> findByPage(IPage<AthleteBO> page, @Param("ew") QueryWrapper<AthleteBO> queryWrapper) throws Exception;

}

说明一下条件构造器

QueryWrapper条件构造器对象的sqlSegment属性拼接了 不带where 的筛选条件sql，而customSqlSegment属性拼接了 完整的 where语句 。
mapper代码

<select id="findByPage" resultType="com.cbs.model.participant.AthleteBO">
        SELECT
            ath.* ,
            nation.nation_name,
            pro.project_name_cn,
            unit.unit_name
        FROM
            cbs_athlete ath
        LEFT JOIN sys_nation_conf nation ON ath.nation_code = nation.nation_code
        LEFT JOIN cbs_examination_project pro on ath.project_id = pro.id
        LEFT JOIN cbs_reference_unit unit on ath.reference_unit_id = unit.id
        ${ew.customSqlSegment}
    select>

service层把筛选字段和值set进条件构造器对象后，在mapper中直接在查询语句后面使用$符号直接进行拼接，需要注意的是dao的入参需要在@param注解上表明

@Param("ew") QueryWrapper<AthleteBO> queryWrapper

而mapper文件中对应的使用

${ew.customSqlSegment}

已经测试使用’ew’以外字符将会报错，通过QueryWrapper的paramAlias属性为’ew’推测可能在底层二次覆盖了，初步使用阶段暂未证明。

service接口代码

public interface IAthleteService extends IService<AthleteBO> {

    IPage<AthleteBO> findByPage(Long current, Long size, Long unitId, String athleteName, Long projectId, Long groupId) throws Exception;
}

service实现类代码

public class AthleteServiceImpl extends ServiceImpl<IAthleteDao,AthleteBO>{
	@Resource
    private IAthleteDao athleteDao;
    
	@Override
    public IPage<AthleteBO> findByPage(Long current, Long size, Long unitId, String athleteName, Long projectId, Long groupId) throws Exception {
    	//分页器对象
        IPage<AthleteBO> page = new Page<AthleteBO>(current, size);
		//条件构造器对象
        QueryWrapper<AthleteBO> queryWrapper = new QueryWrapper<AthleteBO>();
        
		//入参
        if (unitId!=null){
            queryWrapper.eq("reference_unit_id", unitId);
        }
        if (StringUtils.isNotBlank(athleteName)){
            queryWrapper.like("name", athleteName);
        }
        if (projectId!=null){
            queryWrapper.eq("project_id",projectId);
        }
        if (groupId!=null){
            queryWrapper.eq("group_id",groupId);
        }
        queryWrapper.eq("ath.is_enabled", true);
        queryWrapper.orderByAsc("group_id");

        IPage<AthleteBO> athleteBOIPage = null;
        try {
            athleteBOIPage = this.athleteDao.findByPage(page, queryWrapper);
        } catch (Exception e) {
            LOGGER.error(e.getMessage());
            throw e;
        }
        return athleteBOIPage;
    }
 }

除此之外，IService 接口 定义 并在实现类实现了很多 基础的方法，特别是增删改的封装，可以在业务层直接进行调用。
略微总结一下使用的心得
1.对于敏捷开发有不错的提升，入门简单，对于个别项目十分适用
2.减少了基础的增删改的代码量，再也不用写冗长的新增和更新sql了
3.分页器十分便捷，只需要传入并return Page对象即可。
4.萌新斗胆问一句，是不是有点包装过头了？实际上过深的包装不利于处于摸索阶段的新手对于底层的理解，而且在entity使用了过多的注解。当然这是我的小小看法。

希望 路过的大神能对我写的谬误指点一二，还有很多不理解的。多谢多谢！