黑马商城微服务踩坑及理解记录-MP部分

第一天---MyBatisPlus基础部分

1.jdk版本 是自己配的情况下 导入实例代码及其容易 pom.xml  中lombok版本 与 jdk版本不服导致j

解决Class com.sun.tools.javac.tree.JCTree$JCImport does not have member field ‘com.sun.tools.javac.tre-优快云博客

2.mybatisplus依赖导入了 就不要留着mybatis依赖了 二者是有一定兼容要求的 

3.​​JUnit 单元测试在默认情况下不会随着 Spring Boot 启动类（即 main方法）的执行而自动运行​​。两者的执行流程是独立的，需通过特定配置或命令触发测试  因此在mp 资料代码 mvc架构不全的情况下依然可以在test类里面 debug mybatis-plus

4.MyBatis-Plus 的实体类与数据库表字段自动映射机制 ​​充分体现了“约定大于实现”​​ 的设计原则

分为表名、主键名、字段名映射  如果粗心的话要用@tableName等注解重新建立三部分二者之间的联系   就数据库而言 分为 自增 手动设置 mp分配三种id   其中数据库的主键和实体类设置的如果是auto类型  否则是雪花算法插入随机id 

就可以像苍穹外卖原生mybatis那样不去插入id 或者在这里不管id  ①mp还会 去把实体类里的 bool is Married  去掉married  此时也要加tableField   ②数据库关键字段 与实体类属性名称冲突加``

③不插入某个字段 tablefield(exist = false)

5.常见配置

---------------------------------------------------------------------------------------------------------------------------------

第二天：MyBatisPlus核心功能

1.条件查询

querywrapper等wrapper 实现条件构造

虽然写起来还是费点力 至少不用在xml里debug了

为了解决可扩展性低的问题  可以用回调get方法来替换条件属性usr::geter

总结下来 特定查询更新用对应的wrapper  否则用baseMApper的增删

2.半自动（自定义）SQL

这个相当于生成了一个 update user set banlance -= amount  where id in"(id1,id2,....idn  )"  半自动指的除了where其余手写   替换成上面的in 就会很方便

在前面的1.中通过eq和原生update实现了 固定化快捷update  但这样有个问题  就是值写死了  

没办法处理灵活情况  所以要用eW自定义sql  这里同样是  为了不写复杂xml拼接语句  但是却让流程更繁琐  这本身理解成各项要求之间的tradeoff

于是就有个这种即麻烦 又难记的东西 难理解程度远超mybatis

--------------------------------------------------------------------------------------------------------------------------

第三天--MybatisPlus核心用法

1.IService 比BaseMapper方法要多  批量插入操作  之前要看有没有传递id 来判断是插入还是更改 ,然后遍历   现在直接insertbatch  怪不得 前面的springboot单体项目 给函数起名批量操作也是***bacth 关于iservice 随便举一个例子 ：   能看出来接口很多

此处用法不太一样 偏记忆性  因此 截图圈重点

2. Iservice要继承 既要MVC中的service接口  继承  方法定义的Iservice  也需要service的impl去 继承iservice 的impl  这点和mapper继承baseMapper还是不一样的 我虽然不能完全理解 但是这两件事一个是service层  一个是mapper层的事情，查了下原因是：deepseek回答留档如下：

本质上源于 ​​框架对数据访问层（DAO）和业务逻辑层（Service）的实现机制不同​​。以下是具体原

---

一、核心差异对比

​​维度​​	​​Mapper 继承 BaseMapper​​	​​Service 继承 IService​​
​​方法实现来源​​	由 MyBatis-Plus 框架动态代理生成	需开发者手动实现或继承 ServiceImpl
​​默认实现机制​​	框架通过 XML 或注解自动生成 SQL	IService无默认实现，需依赖 ServiceImpl
​​设计目标​​	简化数据库操作，屏蔽 SQL 编写细节	封装通用业务逻辑，支持扩展和复用

---

二、Mapper 继承 BaseMapper 的实现原理

1. ​​动态代理机制​​

• ​​MyBatis-Plus 的 Mapper 代理​​：

  当 Mapper 接口继承 BaseMapper时，MyBatis-Plus 通过 MyBatis 的 MapperProxy动态生成代理类，自动实现接口中声明的所有方法（如 insert、selectById等）。

2. ​​无需手动实现的原因​​

• ​​框架接管实现​​：BaseMapper的方法由框架处理，开发者只需关注业务逻辑，无需编写 SQL 或方法体。

• ​​泛型映射​​：BaseMapper<T>通过泛型参数 T自动关联实体类和数据库表。

---

三、Service 继承 IService 的设计逻辑

1. ​​默认实现依赖​​

• ​​IService的空实现​​：

  IService接口本身仅定义方法签名（如 save、removeById），​​无默认实现​​。若需使用其功能，必须通过继承 ServiceImpl（如 ServiceImpl<M, T>）来获得基础实现。

2. ​​Service 实现类必须实现接口的原因​​

• ​​接口约束​​：Java 接口的方法默认是抽象的，实现类必须提供具体实现。

• ​​业务扩展需求​​：IService仅定义通用方法，具体业务逻辑需在 ServiceImpl或自定义 Service 类中实现。

---

四、设计哲学对比

1. ​​Mapper 层（DAO）​​

• ​​职责单一​​：仅负责数据库操作，由框架代理实现，开发者无需关注 SQL。

• ​​解耦​​：实体类与 Mapper 接口通过泛型自动关联，减少样板代码。

2. ​​Service 层（业务逻辑）​​

• ​​业务封装​​：需开发者显式实现业务逻辑，支持复杂操作（如事务控制、多表关联）。

• ​​扩展性​​：通过继承 ServiceImpl复用通用逻辑，同时允许自定义扩展。构造函数用到了   ----------------------------  -- ----------------------                                                                                              除此之外mapper作为参数

• 

 看得出来iservice 其实和basemapper的差异确实是service层和mapper的差异

总的来说（i）想在mapper写sql/半自动sql 就用basemapper和querywrapper

                  (ii)    想用service实现查询就用,但是二者底层都是mapper 因为iservice实现类就含mapper构造

                (iii) iservice 由于更上层且包含了mapper所有方法 所以能在controller 用iservice的方法就别用mapper  

                (iv)查一个用iservice.get  查多个iservice.list()

3.service impl 既要 extends ServiceImpl(怪不得此处service自己写的实现类名字都会带上对象)，又要implements接口 同时  要按照②处写法

4.alt+enter可以创建类的测试类

5.此外我发现导入dto 现成的实体类也会让依赖失效  这时候和导入依赖一样还是得重新加载maven

6.不知道为什么要静态注入对象变成编译后静态变量的写法 说是spring推荐  好像确实苍穹外卖编译前有这个warning

7.高版本jdk(>11)用Listof初始化List对象

8.

直接get即可 无需从service对象调用iservice  这里先判断用户状态再sql 推测复杂更新要半自动sql处理

8.多条件查询需要多pathvariable接受  一般设置新的dto包含所有查询值的dto 作为lamda编程更节省时间

9.复杂查询还可以用lambda来补全  讲的是真乱  我现在只能理解成简单crud 在controller调用Iservice  复杂查询在service调用Iservice的lamdachainWrapper 后续自己再整理把

10.我才知道封装好的spring框架要求getMapping 不能用json接收  因此此处query类查询 用的putmapping

10.Iservice 的lamba还可以改造

11.多线程同时写入问题

12.lamba批处理 于遍历多次插入性能对比

维度​​	for-each单体插入	IService批处理
​​网络开销​​	高（多次请求）	低（单次请求）
​​数据库解析​​	低效（重复解析 SQL）	高效（单次解析）
​​事务成本​​	高（多次提交）	低（单次提交）
​​吞吐量​​	低（受限于单线程）	高（支持并行处理）

也就是说原生mybatis动态for-each拼接sql是批量插入 是很多数据实体生成了一条极长的sql  一次性插入的 也就是说java代码foreach多次操作mysql是多次请求插入效率低 而mybatis  mapper.xml中for-each 多次遍历collections是循环遍历元素拼接  此乃构成一个批量插入的一条sql

---------------------------------------------------------------------------------------------------------------------------------

mp基础学习完结感言：学了这些第二天早上会觉得自己没白过  运动断了可能会回到原点 减肥断了可能会反弹  但是学习最多只会停滞  让我想起了 高中的时候 每天都在心流一样的学习  高中三年周一到周五全力学习锻炼    上了大学没找到过这种感觉了 大三 找工作多准备点  但还是杯水车薪  要是再让我读一次大学 不说保研 进中央选调  起码不要让自己后悔，虽然努力不努力 可能都是现在这样进学历厂 但还是感觉大学有点白过了

--------------------

结尾说明：由于本人某9混子毕业  在某血汗公司搞软硬结合  常态化加班被拷打幡然醒悟   后续每天晚上下班后都会学习 spirngboot/cloud/AI 等知识  每天都会更新下一个问题或者理解作为笔记