前言

MP 從出現(xiàn)就一直有爭議 感覺一直 都存在兩種聲音

like：

很方便啊 通過函數(shù)自動拼接Sql 不需要去XML 再去使用標簽 之前一分鐘寫好的Sql 現(xiàn)在一秒鐘就能寫好 簡直不要太方便

dislike：

侵入Service層 不好維護 可讀性差 代碼耦合 效率不行 sql優(yōu)化比較難

之前也有前輩說少用MP 理由就是不好維護 但是這個東西真的是方便 只要不是強制不讓用 就還是會去使用 存在集合里 最近也確實有一些體會 就從兩個角度去看一下MP

優(yōu)點

操作簡潔

就從我們編碼中最常用的增刪改查去說

按照我們之前去使用Mybatis的喜歡我們就要去建立一個XML文件 去編寫Sql語句 算是半自動 我們可以直接去操控Sql語句 但是會比較麻煩 很多簡單的數(shù)據(jù)查詢我們都要去寫一個標簽 感覺這種沒有意義的操作還是比較煩的 那么MP里面怎么實現(xiàn)

第一種：最簡單我們就是直接去使用提供的方法 我們非常簡單就能做到這些操作 但是這個就有一個問題

nodeMapper.selectById(1);
nodeMapper.deleteById(2);
nodeMapper.updateById(newNode());
nodeMapper.insert(newNode());

維護性差 以查詢?yōu)槔?這個默認提供的方法都是查詢所有字段我們都知道在編寫Sql的時候第一條優(yōu)化準則就是不要使用Select * 因為這種寫法是很Low

這個就是上面selectById執(zhí)行的結果

SELECTId,name,pidFROMnodeWHEREId=?

這種Sql 肯定是不好的所以我們在使用MP的時候盡量不要去使用自帶的快捷查詢 我們可以去使用它里面的構造器

nodeMapper.selectOne(newQueryWrapper().eq("id",1).select("id"));

這匯總寫法 我們可以通過后面的select() 去指定我們需要查詢的字段 算是解決上面那個問題嗎 但是這個就完事了嗎？這還有一個問題

我們在開發(fā)中經(jīng)常會說一個叫魔法值的東西

//這個就是魔法值
if("變成派大星".equals(node.getName())){
System.out.println("魔法值");
}

之所以不要多用魔法值就是為了后期維護 我們建議使用枚舉 或者建一個常量類 通過Static final修飾

上面那段代碼是不是也有同樣問題 "id"算不算魔法值呢 這種構造器產(chǎn)生的問題就是 不好維護

假設 我們的這Node類是高度使用的 我們到處都在寫

nodeMapper.selectOne(newQueryWrapper().eq("id",1).select("id"));

剛開始沒事 我們樂呵呵的 但是一旦我去修改Id 的字段名怎么辦

我修改成test（數(shù)據(jù)庫同步修改） 現(xiàn)在這個實體類中沒有這個字段 我們再去看我們的代碼

沒有什么反應 沒有給我提示報錯 我這個時候去運行怎么辦 我要一個個去找這個錯誤嗎 這明顯很費時間

這個確實是一個問題 但是也是可以解決的

Nodenode=nodeMapper.selectOne(newLambdaQueryWrapper().eq(Node::getId,1).select(Node::getId));

上面這種代碼就可以去解決這個問題 我們在使用的時候可以多用這個東西

一旦修改字段就會立馬報錯

但是 這就萬事大吉了嗎 NO No NO 我們要是處理稍微復雜的語句怎么辦？比如如我們字段求和 這個LambdaQueryWrapper還是存在限制的

如果我們想實現(xiàn)這種 怎么去做呢

selectSUM(price_count)frombla_order_dataLIMIT100

首先這種寫法肯定是不太行的 編譯不通過

除非去使用QueryWrapper

還有就是分頁查詢

//條件查詢
LambdaQueryWrapperqueryWrapper=newLambdaQueryWrapper<>();
queryWrapper.eq(UserInfo::getAge,20);
//分頁對象
PagequeryPage=newPage<>(page,limit);
//分頁查詢
IPageiPage=userInfoMapper.selectPage(queryPage,queryWrapper);
//數(shù)據(jù)總數(shù)
Longtotal=iPage.getTotal();
//集合數(shù)據(jù)
Listlist=iPage.getRecords();

這個還是非常簡單的

簡單總結

MP 在做一些簡單的單表查詢可以去使用但是對于一些復雜的SQl操作還是不要用

1、SQL侵入Service 的問題我們可以仿照 Mybatis 建一個專門存放 MP查詢的包

2、關于維護性 我們可以盡量去使用 LambdaQueryWrapper 去構造

3、MP是有內置的主鍵生成策略

4、內置分頁插件：基于 Mybatis 物理分頁，開發(fā)者無需關心具體操作，配置好插件之后，寫分頁等同于普通List查詢。

缺點

我就說一個最大的缺點就是對于復雜Sql 的操作性很不舒服 比如我們去多表查詢 你怎么去寫呢

看一個例子

就是通過 @Select 注解將Mp的查詢條件嵌入進去${ew.customSqlSegment}

咱就是一整個大問號 聯(lián)表老老實實去寫XML吧 這種真的不要去用 太丑了

總結

沒有過多的東西 基本都是最近看到的東西

1、復雜語句不推薦使用MP 能用最好也別用 可讀性差 難維護 使用剛開始沒感覺 后期業(yè)務擴充 真的惡心的

2、可以使用MP中的分頁 比較舒服 逐漸生成策略也舒服

3、盡量不要去使用MP中自帶的selectById 等全表查詢的方法

4、盡量使用LambdaQueryWrapper的書寫形式 至少比較好維護

5、簡單重復Sql 可以用MP。復雜SQL不要用

審核編輯：劉清