Continuez à créer, accélérez la croissance ! C'est le 17ème jour de ma participation au "Nuggets Daily New Plan · October Update Challenge", cliquez pour voir les détails de l'événement
avant-propos
MP fait polémique depuis son apparition, il y a toujours eu deux voix.
like：
C'est très pratique. Épissage automatique de Sql à travers des fonctions. Vous n'avez pas besoin d'aller à XML pour utiliser des balises. Sql écrit en une minute avant peut être écrit en une seconde. Ce n'est pas trop pratique.
dislike：
L'intrusion dans la couche Service n'est pas bonne, la maintenance est mauvaise, la lisibilité est mauvaise, l'efficacité du couplage de code n'est pas bonne, l'optimisation SQL est difficile
Il y avait aussi des personnes âgées qui ont dit que la raison d'utiliser moins de MP est qu'il n'est pas facile à entretenir, mais cette chose est vraiment pratique. Tant qu'il n'est pas obligé de l'utiliser, je l'utiliserai toujours. Dans la collection existante , J'ai une expérience récente. Regardons le député sous deux angles.
avantage
Opération simple
Parlons des ajouts, des suppressions et des modifications les plus couramment utilisés dans notre codage.
Selon ce que nous aimions utiliser Mybatis auparavant, nous devons créer un fichier XML pour écrire des instructions Sql, ce qui est semi-automatique. Nous pouvons directement manipuler des instructions Sql, mais ce sera plus gênant. Pour de nombreuses requêtes de données simples, nous avons pour écrire une étiquette, ce qui n'a aucun sens. L'opération est encore assez ennuyeuse, alors comment l'implémenter dans MP
La première : la méthode la plus simple consiste à utiliser directement la méthode fournie. Nous pouvons effectuer ces opérations très simplement, mais il y a un problème avec cette méthode.
nodeMapper.selectById(1);
nodeMapper.deleteById(2);
nodeMapper.updateById(new Node());
nodeMapper.insert(new Node());
复制代码维护性差Prenons l'exemple de query, la méthode par défaut est d'interroger tous les champs, nous savons tous que le premier critère d'optimisation lors de l'écriture Sql est de ne pas utiliser Select * car cette méthode d'écriture est très faible.
Ceci est le résultat de l' selectByIdexécution ci-dessus
SELECT Id,name,pid FROM node WHERE Id=?
复制代码Ce type de Sql n'est certainement pas bon, nous essayons donc de ne pas utiliser la requête rapide intégrée lors de l'utilisation de MP, nous pouvons utiliser le constructeur dedans
nodeMapper.selectOne(new QueryWrapper<Node>().eq("id",1).select("id"));
复制代码Avec ce résumé, nous pouvons utiliser le select() suivant pour spécifier les champs que nous devons interroger pour résoudre le problème ci-dessus, mais est-ce la fin ? Il y a un autre problème
Nous disons souvent 魔法值quelque chose appelé dans le développement
//这个就是魔法值
if ("变成派大星".equals(node.getName())){
System.out.println("魔法值");
}
复制代码La raison de ne pas utiliser plus de valeurs magiques est pour une maintenance ultérieure. Nous vous recommandons d'utiliser l'énumération ou de construire une classe constante à modifier par Static final.
上面那段代码是不是也有同样问题 "id"算不算魔法值呢 这种构造器产生的问题就是 不好维护
假设 我们的这Node类是高度使用的 我们到处都在写
nodeMapper.selectOne(new QueryWrapper<Node>().eq("id",1).select("id"));
复制代码刚开始没事 我们乐呵呵的 但是一旦我去修改Id 的字段名怎么办
我修改成test（数据库同步修改） 现在这个实体类中没有这个字段 我们再去看我们的代码
没有什么反应 没有给我提示报错 我这个时候去运行怎么办 我要一个个去找这个错误吗 这明显很费时间
这个确实是一个问题 但是也是可以解决的
Node node = nodeMapper.selectOne(new LambdaQueryWrapper<Node>().eq(Node::getId, 1).select(Node::getId));
复制代码上面这种代码就可以去解决这个问题 我们在使用的时候可以多用这个东西
一旦修改字段就会立马报错
但是 这就万事大吉了吗 NO No NO 我们要是处理稍微复杂的语句怎么办？ 比如如我们字段求和 这个LambdaQueryWrapper还是存在限制的
如果我们想实现这种 怎么去做呢
select SUM(price_count) from bla_order_data LIMIT 100
复制代码首先这种写法肯定是不太行的 编译不通过
除非去使用QueryWrapper
还有就是分页查询
// 条件查询
LambdaQueryWrapper<UserInfo> queryWrapper = new LambdaQueryWrapper<>();
queryWrapper.eq(UserInfo::getAge, 20);
// 分页对象
Page<UserInfo> queryPage = new Page<>(page, limit);
// 分页查询
IPage<UserInfo> iPage = userInfoMapper.selectPage(queryPage , queryWrapper);
// 数据总数
Long total = iPage.getTotal();
// 集合数据
List<UserInfo> list = iPage.getRecords();
复制代码这个还是非常简单的
简单总结
MP 在做一些简单的单表查询可以去使用但是对于一些复杂的SQl操作还是不要用
1、SQL侵入Service 的问题我们可以仿照 Mybatis 建一个专门存放 MP查询的包
2、关于维护性 我们可以尽量去使用 LambdaQueryWrapper 去构造
3、MP是有内置的主键生成策略
4、内置分页插件：基于 Mybatis 物理分页，开发者无需关心具体操作，配置好插件之后，写分页等同于普通List查询。
缺点
我就说一个最大的缺点就是对于复杂Sql 的操作性很不舒服 比如我们去多表查询 你怎么去写呢
看一个例子
就是通过
@Select 注解
将Mp的查询条件嵌入进去
${ew.customSqlSegment}
复制代码咱就是一整个大问号 联表老老实实去写XML吧 这种真的不要去用 太丑了
总结
没有过多的东西 基本都是最近看到的东西
1、复杂语句不推荐使用MP 能用最好也别用 可读性差 难维护 使用刚开始没感觉 后期业务扩充 真的恶心的
2、可以使用MP中的分页 比较舒服 逐渐生成策略也舒服
selectById3. Essayez de ne pas utiliser la méthode de requête de table complète fournie avec MP
4, essayez d'utiliser LambdaQueryWrapperla forme d'écriture au moins mieux pour maintenir
5, simple répétition Sql peut utiliser MP. N'utilisez pas de SQL complexe
Si vous y réfléchissez, vous l'ajouterez. Les collègues ont d'autres opinions. Vous pouvez les voir dans la zone de commentaires pour des compléments et des corrections.