前言：今天在复习项目的时候更新了 MyBatis-Plus 的依赖版本，发现原本好好的 Service 层代码报错了，细看是 MyBatis-Plus 的 IService 和 ServiceImpl 的原因。在通过查询官网后，发现官网提到了一个 Repository 层的概念，经过替换后，代码回归正常，这下我就好奇了，Repository 层是什么？MyBatis-Plus 为什么要加一个这东西？
一、官网原文
二、为什么原本的架构会造成语义混乱
之前使用的时候我还真没考虑过这方面的问题。在经过一段时间的了解后，我发现 MyBatis-Plus 的这个操作还是有他的道理的。
首先要明白什么叫语义混乱，我们都知道，后端基本架构分为三层：Controller -> Service -> Dao (Mapper)。这三层各司其职，互相独立，其中 Service 层的职责是纯粹的业务逻辑（如：算费率、发短信、多表组装）。但是，MyBatis-Plus 原先的做法打破了这种隔离，他使得 Service 层也有了直接与数据库交互的能力，即与 Mapper 层的功能出现了重叠，这就是为什么说其造成了语义层面的混乱。
三、为什么说 MyBatis-Plus 原先的做法打破了这种隔离
首先看看我们使用原生 MyBatis 是怎么做的，我们通过 Spring Boot 的依赖注入的方式来完成这三层之间的互相调用。我们都知道，依赖注入本来就有解耦合的作用。但是在使用 MyBatis-Plus 时，我们在 Service 层并不是通过依赖注入完成的，下面看例子：
@Service
public class UserServiceImpl extends ServiceImpl<UserMapper, User> implements IUserService {
@Override
public void registerUser(User user) {
// 1. 处理业务逻辑（如校验、加密）
user.setPassword(encrypt(user.getPassword()));
// 2. 直接调用继承自 ServiceImpl 的单表插入方法
this.save(user);
}
}
MyBatis-Plus 使用了一个类似继承的方式将 mapper 提供给了 Service 层，这样虽然方便，但是他把 mapper 的方法一并继承给了 Service，打破了之前的那种各司其职的关系。现在我们在 controller 层可以通过调用 Service 去直接的操作数据库。
正因如此，MyBatis-Plus 官方现在加入了 Repository 层，其正是为了隔离 Service 。
四、明明 MyBatis-Plus 只需要增强 mapper 层就够了，为什么要动Service层
总结一下：单独一个mapper层没有办法满足mybatis-plus的想法，他们还需要一个真正地类去实现复杂的SQL语句，而不是仅仅作为一个简单SQL大全。
现在有点晚了，我把AI说的原因贴出来。本文主要用于复习，如果有错误希望指出，谢谢！
