面向API

Note

MybatisPlus,对MyBatis的增强,最大的好处就在于无侵入式增强
引入MP之后可以自动基础的增删改查、封装好分页插件
他有一个特点就是支持面向API编程,但其实这算不上多好
因为面向API编程虽然方便了我们开发
但是却并不利于后期维护
而且很难控制性能

所以一个使用建议就是基础的增删改查、分页可以直接用(单表操作可以用MP)
但是复杂的SQL,涉及多表还是建议手写,在xml中配置

构建queryWrapper,再使用它作为其他方法的查询条件,
也支持子SQL嵌套的API语法,但是真心不好用,直接写SQL和xml配置比他想多了

QueryWrapper和LambdaQueryWrapper

LambdaQueryWrapperQueryWrapper都是MyBatis-Plus中用于构建查询条件的类,它们的主要区别在于使用方式和语法。

  1. 使用方式:

    • QueryWrapper:使用字符串指定实体类的属性名。
    • LambdaQueryWrapper:使用 lambda 表达式指定实体类的属性。
  2. 语法:

    • QueryWrapper:使用字符串指定实体类的属性名,例如 eq("username", "admin")like("email", "@example.com")
    • LambdaQueryWrapper:使用 lambda 表达式指定实体类的属性,例如 eqlike
  3. 类型安全:

    • QueryWrapper:由于使用字符串指定属性名,编译器无法检查属性名是否正确,存在拼写错误或者属性不存在的风险。
    • LambdaQueryWrapper:使用 lambda 表达式指定属性,可以在编译时进行类型检查,提供了更好的类型安全性。
  4. 性能:

    • 在性能方面,QueryWrapperLambdaQueryWrapper的性能差异不大,因为它们在内部都会转换为相同的 SQL 语句进行执行。

因此,如果你更倾向于使用类型安全的方式来构建查询条件,并且希望在编译时能够发现潜在的错误,推荐使用LambdaQueryWrapper。而如果你更习惯于使用字符串指定属性名,并且不太担心属性名拼写错误的问题,可以继续使用QueryWrapper

LambdaQueryWrapper和LambdaQueryChainWrapper

LambdaQueryWrapperLambdaQueryChainWrapper都是MyBatis-Plus提供的用于构建查询条件的工具类,但它们在使用方式和功能上有一些区别。

  1. LambdaQueryWrapper:

    • LambdaQueryWrapper是用于构建单个查询条件的工具类。你可以通过LambdaQueryWrapper来构建各种查询条件,例如等值查询、范围查询、模糊查询等。
    • 使用LambdaQueryWrapper时,你需要显式地创建一个LambdaQueryWrapper对象,并通过其提供的方法来设置查询条件。
    • 通常情况下,你可以通过lambda表达式来指定实体类的属性,以便在查询条件中使用。
  2. LambdaQueryChainWrapper:

    • LambdaQueryChainWrapper是用于构建链式查询条件的工具类。你可以通过LambdaQueryChainWrapper来构建一系列的查询条件,并最终执行查询操作。
    • 使用LambdaQueryChainWrapper时,你无需显式地创建一个LambdaQueryWrapper对象,而是可以通过lambda表达式直接调用方法来设置查询条件。
    • LambdaQueryChainWrapper提供了一系列链式调用的方法,例如eqlikege等,这些方法可以直接作用于实体类的属性上。

下面是一个简单的示例,展示了如何使用LambdaQueryWrapperLambdaQueryChainWrapper来构建查询条件:

import com.baomidou.mybatisplus.core.conditions.query.LambdaQueryWrapper;
import com.baomidou.mybatisplus.core.conditions.query.QueryWrapper;
import com.baomidou.mybatisplus.extension.conditions.query.LambdaQueryChainWrapper;

public class ExampleService {

    // 使用LambdaQueryWrapper构建查询条件
    public void queryWithLambdaQueryWrapper() {
        LambdaQueryWrapper<User> queryWrapper = new LambdaQueryWrapper<>();
        queryWrapper.eq(User::getUsername, "admin")
                    .gt(User::getAge, 18)
                    .like(User::getEmail, "@example.com");

        // 执行查询操作
        List<User> userList = userDao.selectList(queryWrapper);
    }

    // 使用LambdaQueryChainWrapper构建查询条件
    public void queryWithLambdaQueryChainWrapper() {
        List<User> userList = new LambdaQueryChainWrapper<>(userDao)
                                    .eq(User::getUsername, "admin")
                                    .gt(User::getAge, 18)
                                    .like(User::getEmail, "@example.com")
                                    .list();
    }
}

在上面的示例中,queryWithLambdaQueryWrapper方法使用了LambdaQueryWrapper来构建查询条件,而queryWithLambdaQueryChainWrapper方法使用了LambdaQueryChainWrapper来构建查询条件。两种方法都可以用于构建复杂的查询条件,只是在使用方式上有些许不同。

this.mapper

自己对应的mapper不需要注入,直接this即可

IDEA插件MyBatisX

bug:单独只生成xml就会有问题,得跟mapper接口一起生成

另外,请最好一次性设计完好的数据库表,后期修改会很麻烦
如果只是增添一个字段那么手动修改文件就不要再使用插件自动生成了,可能得不偿失更麻烦

因为MP的编译期检查,对泛型是有严格约束的,但凡有一个地方出错都跑不起来的

其他

xml中写SQL配置对内部类支持不好,可能无法实例化导致出错

MP封装了一些Base服务类,一般下面这般使用:

  • Controller层注入Service
  • ServiceImpl注入Mapper
    如果同一层注入两者,可能会出现循环依赖问题无法启动应用