MyBatis-Plus 对于Mapper和Service的使用

在后端开发中使用到mybatis-plus时，会发现在其内部存在着两种数据库操作接口，Iservice和BaseMapper，如果只是用增删改查，会发现除了方法名称不同外，两者的功能是一致的。那如何在开发中进行合理的选择？

首先应该知道的是，mybatis-plus 提供两种包含预定义增删改查操作的接口和一个类：

• BaseMapper 接口：针对dao/mapper层的方法封装 CRUD
• IService<T> 接口：针对业务逻辑层的封装需要指定Dao层类和对应的实体类 是在BaseMapper基础上的加强
• ServiceImpl<M extends BaseMapper<T>, T> 类：针对业务逻辑层的实现

其中，BaseMapper 接口和IService<T> 接口有以下差异:

• 方法命名差异：比如，插入数据：在BaseMapper使用 insert，在IService使用 save ；
• IService 提供了批处理操作的方法，而 BaseMapper 没有提供相应的批处理操作；
• IService 依赖于 Spring 容器，而 BaseMapper 不依赖；
• 如果既要使用批处理操作，又要添加自己的数据库操作，那就必须两个接口一起用。

案例说明

Mapper简化了单表的sql操作步骤（CRUD），而Serivce实现的了更加丰富的CRUD，加入了很多批处理功能。但是必须依赖Mapper，因此需要编写Mapper接口。

Service CRUD 接口

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

/**
 * 订单 服务类
 */
public interface IOrderService extends IService<Order> {
    // 无需编写任何方法，继承 IService 即可使用通用的 CRUD 方法
}

IOrderService 接口扩展了 MyBatis-Plus 提供的 IService<Order> 接口，表示它定义了与 Order 实体相关的业务逻辑方法。IService<Order> 接口是 MyBatis-Plus 的一部分，提供了一组通用的服务方法，包括常见的 CRUD（创建、读取、更新、删除）操作。

Mapper CRUD 接口

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

/**
 * 订单 Mapper 接口
 */
public interface OrderMapper extends BaseMapper<Order> {
    // 无需编写任何方法，继承 BaseMapper 即可使用通用的 CRUD 方法
}

OrderMapper 接口继承了 MyBatis-Plus 提供的 BaseMapper<Order> 接口，这意味着它会继承一系列通用的数据库操作方法，包括常见的查询、插入、更新、删除等 CRUD 操作。这样的设计遵循了 MyBatis-Plus 的规范，使得开发者无需手动实现这些通用的数据库操作，而是可以直接在 OrderMapper 接口中使用这些方法。

ServiceImpl<M extends BaseMapper<T>, T> 类

M 是mapper对象，T 是实体

ServiceImpl 是 MyBatis-Plus 提供的通用 Service 实现类。它已经实现了 IService 接口，包含了通用的 CRUD 方法的实现。在你的业务 Service 实现类中，可以直接继承 ServiceImpl，从而获得这些通用的数据库操作方法。

/**
 * 订单 服务实现类
 */
@Service
@RequiredArgsConstructor
public class OrderServiceImpl extends ServiceImpl<OrderMapper, Order> 
							  implements IOrderService {
	// 无需额外编写方法，继承 ServiceImpl 即可使用通用的 CRUD 方法
}

OrderServiceImpl 是 IOrderService 接口的实现类，通过继承 ServiceImpl<OrderMapper, Order>，该类直接继承了 MyBatis-Plus 提供的默认 Service 实现，并指定了泛型参数为 OrderMapper 和 Order。因此，OrderServiceImpl 中无需额外编写方法，即可直接使用 ServiceImpl 中提供的通用的 CRUD 方法。

再根据项目看一下对应的继承关系图

既然ServiceImpl类也实现了IService接口，那么如果UserServiceImpl直接继承ServiceImpl类不就行了吗？为何还要自定义一个继承了IService接口的IUserService接口?

这是因为Spring自动注入要求是以接口为标准，在Controller里注入的Service要是一个接口才符合Spring的规范(当然注入类也行)!

Mapper和IService的使用场景

使用 Mapper的场景：

1. Mapper 主要用于执行数据库的 CRUD 操作，包括查询、插入、更新和删除等底层数据库访问操作。
2. 定如果你有一些定制化的 SQL 需求，或者需要使用 MyBatis 的 XML 映射文件，那么直接使用 Mapper 可能更合适。你可以在 Mapper 接口中定义自己的 SQL 方法，并在 XML 文件中编写相应的 SQL 语句。
3. 底层数据库访问： 如果你的操作更偏向于底层的数据库访问，例如需要直接操作数据库中的某个字段，或者使用一些特殊的 SQL 查询，那么直接使用 Mapper 会更直观和方便。使用 IService的场景：
4. IService 主要用于定义业务逻辑层的接口，包括业务相关的操作方法。它提供了一些通用的业务逻辑方法，如保存、查询、更新等，更适用于业务操作。
5. 如果你的操作涉及到事务，IService 提供了一些事务控制的方法，例如 saveOrUpdate，适合在业务逻辑层进行事务控制。
6. IService 更抽象，更适用于高层次的业务操作。它对业务逻辑进行了封装，使得业务代码更清晰，易于维护。

组合使用：

在项目的一般开发流程中，先定义Mapper接口和对应的XML文件实现对数据库的操作，然后在Service层中注入Mapper接口的实例，并调用Mapper的方法来实现业务逻辑，提供更高层次的抽象和封装。

因此在项目开发中，通常会同时使用 Mapper 和 IService，将数据访问层和业务逻辑层分离。Mapper 用于处理底层数据库访问，而 IService 用于封装业务逻辑。这种组合使用的方式能够更好地利用 MyBatis-Plus 提供的功能，使代码结构更清晰，同时也便于单元测试和维护。

总结：

IService简直是BaseMapper的大扩充，不但包含了所有基本方法，还加入了很多批处理功能。

我正在参与2023腾讯技术创作特训营第三期有奖征文，组队打卡瓜分大奖！