在后端開發(fā)過程中，如果有用到mybatis-plus，肯定會發(fā)現(xiàn)在其內部存在著兩種數(shù)據(jù)庫操作接口，Iservice和BaseMapper，如果只是用增刪改查會發(fā)現(xiàn)兩者的功能是一致的，除了方法名稱有所不同，其他的基本相似。對此，我頗為好奇，便打開兩個接口的源碼進行對比。

先演示一下基本開發(fā)中的繼承關系，手動創(chuàng)建的Service繼承于ServiceImpl，并加載自己創(chuàng)建的Mapper

@Service
public class RestDeptService extends ServiceImpl<RestDeptMapper, RestDept> {

 @Resource
 private RestDeptMapper restDeptMapper;
 
 }
 
 public interface RestDeptMapper extends BaseMapper<RestDept> {
 
 }

如上，就是一般開發(fā)的基本模版代碼，足以滿足各種需求功能，但點開源碼時，便進入新世界的大門。先看一下繼承結構

這樣看，是不是很神奇，我們繼承的ServiceImpl依舊實現(xiàn)了BaseMapper接口和Iservice接口，這就感覺有點啰嗦了，明明我們單獨寫了RestDeptMapper，并且繼承了BaseMapper，現(xiàn)在ServiceImpl還是實現(xiàn)了BaseMapper，那我直接一個Service用下來不就行了，創(chuàng)建兩套類，功能相似，還容易混亂，代碼結構冗余。

本著“存在即合理”的理念，我們對比一下兩個接口的方法。

果然，Service簡直是BaseMapper的大擴充，不但包含了所有基本方法，還加入了很多批處理功能，我們可以看一下官網(wǎng)對這兩種接口的說明。

官網(wǎng)鏈接：https://mp.baomidou.com/guide/crud-interface.html

Service CRUD 接口

說明:

• 通用 Service CRUD 封裝IService接口，進一步封裝 CRUD 采用 get 查詢單行 remove 刪除 list 查詢集合 page 分頁 前綴命名方式區(qū)分 Mapper 層避免混淆，
• 泛型 T 為任意實體對象
• 建議如果存在自定義通用 Service 方法的可能，請創(chuàng)建自己的 IBaseService 繼承 Mybatis-Plus 提供的基類
• 對象 Wrapper 為 條件構造器

Mapper CRUD 接口

說明:

• 通用 CRUD 封裝BaseMapper接口，為 Mybatis-Plus 啟動時自動解析實體表關系映射轉換為 Mybatis 內部對象注入容器
• 泛型 T 為任意實體對象
• 參數(shù) Serializable 為任意類型主鍵 Mybatis-Plus 不推薦使用復合主鍵約定每一張表都有自己的唯一 id 主鍵
• 對象 Wrapper 為 條件構造器

最后本文還是比較水的，只是簡單的看了一下結構而已，沒有太多的深入，總結一下，以我平時粘貼復制的經驗來看，Service雖然加入了數(shù)據(jù)庫的操作，但還是以業(yè)務功能為主，而更加復雜的SQL查詢，還是要靠Mapper對應的XML文件里去編寫SQL語句。

到此這篇關于詳解關于mybatis-plus中Service和Mapper的分析的文章就介紹到這了,更多相關mybatis-plus中Service和Mapper內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論