研究背景：

最近在写sql业务逻辑的时候，发现service也可以构建sql。然后查了一下，发现service比常用的mapper功能更多

开始分析：

在后端开发过程中，如果有用到mybatis-plus，会发现在其内部存在着两种数据库操作接口，Iservice和BaseMapper，如果只是用增删改查会发现两者的功能是一致的，就是方法名称有所不同。对此，首先看一下这两个类的继承关系。

先演示一下基本开发中的继承关系，手动创建的Service继承于ServiceImpl，并加载自己创建的Mapper

@Service
public class RestDeptService extends ServiceImpl<RestDeptMapper, RestDept> {
    @Resource
    private RestDeptMapper restDeptMapper;
}

public interface RestDeptMapper extends BaseMapper<RestDept> {
}

如上，就是一般开发的基本模板代码。下面让我们看一下继承结构




这样看，是不是很神奇，我们继承的ServiceImpl依旧实现了BaseMapper接口和Iservice接口，这就感觉有点啰嗦了，明明我们单独写了RestDeptMapper，并且继承了BaseMapper，现在ServiceImpl还是实现了BaseMapper，那我直接一个Service用下来不就行了，创建两套类，功能相似，还容易混乱，代码结构冗余。

本着“存在即合理”的理念，我们对比一下两个接口的方法。





果然，Service简直是BaseMapper的大扩充，不但包含了所有基本方法，还加入了很多批处理功能，我们可以看一下官网对这两种接口的说明。

Mapper CRUD 接口

说明:

通用 CRUD 封装BaseMapper接口，为 Mybatis-Plus 启动时自动解析实体表关系映射转换为 Mybatis 内部对象注入容器泛型 T 为任意实体对象参数 Serializable 为任意类型主键 Mybatis-Plus 不推荐使用复合主键约定每一张表都有自己的唯一id主键对象 Wrapper 为条件构造器

Service CRUD 接口

说明:

通用 Service CRUD 封装IService接口，进一步封装 CRUD 采用 get 查询单行 remove 删除 list 查询集合 page 分页 前缀命名方式区分 Mapper 层避免混淆，泛型 T 为任意实体对象建议如果存在自定义通用 Service 方法的可能，请创建自己的 IBaseService 继承 Mybatis-Plus 提供的基类对象 Wrapper 为条件构造器

两者大同小异，service接口有着更多的sql构造方式，更加简化了程序员对数据库的操作，但如果涉及多表的复杂sql，还是需要自己写sql