详解关于mybatis-plus中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的大扩充,不但包含了所有基本方法,还加入了很多批处理功能,我们可以看一下官网对这两种接口的说明。
官网链接:
service crud 接口
说明:
- 通用 service crud 封装iservice接口,进一步封装 crud 采用
get 查询单行
remove 删除
list 查询集合
page 分页
前缀命名方式区分mapper
层避免混淆, - 泛型
t
为任意实体对象 - 建议如果存在自定义通用 service 方法的可能,请创建自己的
ibaseservice
继承mybatis-plus
提供的基类 - 对象
wrapper
为
mapper crud 接口
说明:
- 通用 crud 封装basemapper接口,为
mybatis-plus
启动时自动解析实体表关系映射转换为mybatis
内部对象注入容器 - 泛型
t
为任意实体对象 - 参数
serializable
为任意类型主键mybatis-plus
不推荐使用复合主键约定每一张表都有自己的唯一id
主键 - 对象
wrapper
为
最后本文还是比较水的,只是简单的看了一下结构而已,没有太多的深入,总结一下,以我平时粘贴复制的经验来看,service虽然加入了数据库的操作,但还是以业务功能为主,而更加复杂的sql查询,还是要靠mapper对应的xml文件里去编写sql语句。
到此这篇关于详解关于mybatis-plus中service和mapper的分析的文章就介绍到这了,更多相关mybatis-plus中service和mapper内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持!
推荐阅读
-
关于Sequelize连接查询时inlude中model和association的区别详解
-
SQL SERVER中关于exists 和 in的简单分析
-
php中关于self和static代表本类的区别详解
-
详解关于mybatis-plus中Service和Mapper的分析
-
java Ali面试题 关于java中类的加载和执行顺序(详解)
-
关于C++中new、operator new和placement new的区别详解
-
关于jQuery中nth-child和nth-of-type的详解
-
php中关于抽象(abstract)类和抽象方法的问题分析_PHP教程
-
深入解读php中关于抽象(abstract)类和抽象方法的问题分析_PHP教程
-
关于Django ForeignKey 反向查询中filter和_set的效率对比详解