在後端開發過程中，如果有用到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的大擴充，不但包含了所有基本方法，還加入了很多批處理功能，我們可以看一下官網對這兩種介面的說明。

官網連結：https://mp.baomidou.com/guide/crud-interface.html

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內容請搜尋我們以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援我們！