前言

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

like：

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

dislike：

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

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

優(yōu)點(diǎn)

操作簡(jiǎn)潔

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

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

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

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

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

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

SELECTId,name,pidFROMnodeWHEREId=?

這種Sql 肯定是不好的所以我們?cè)谑褂肕P的時(shí)候盡量不要去使用自帶的快捷查詢 我們可以去使用它里面的構(gòu)造器

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

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

我們?cè)陂_發(fā)中經(jīng)常會(huì)說一個(gè)叫魔法值的東西

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

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

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

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

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

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

我修改成test（數(shù)據(jù)庫(kù)同步修改） 現(xiàn)在這個(gè)實(shí)體類中沒有這個(gè)字段 我們?cè)偃タ次覀兊拇a

沒有什么反應(yīng) 沒有給我提示報(bào)錯(cuò) 我這個(gè)時(shí)候去運(yùn)行怎么辦 我要一個(gè)個(gè)去找這個(gè)錯(cuò)誤嗎 這明顯很費(fèi)時(shí)間

這個(gè)確實(shí)是一個(gè)問題 但是也是可以解決的

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

上面這種代碼就可以去解決這個(gè)問題 我們?cè)谑褂玫臅r(shí)候可以多用這個(gè)東西

一旦修改字段就會(huì)立馬報(bào)錯(cuò)

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

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

selectSUM(price_count)frombla_order_dataLIMIT100

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

除非去使用QueryWrapper

還有就是分頁(yè)查詢

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

這個(gè)還是非常簡(jiǎn)單的

簡(jiǎn)單總結(jié)

MP 在做一些簡(jiǎn)單的單表查詢可以去使用但是對(duì)于一些復(fù)雜的SQl操作還是不要用

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

2、關(guān)于維護(hù)性 我們可以盡量去使用 LambdaQueryWrapper 去構(gòu)造

3、MP是有內(nèi)置的主鍵生成策略

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

缺點(diǎn)

我就說一個(gè)最大的缺點(diǎn)就是對(duì)于復(fù)雜Sql 的操作性很不舒服 比如我們?nèi)ザ啾聿樵?你怎么去寫呢

看一個(gè)例子

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

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

總結(jié)

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

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

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

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

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

5、簡(jiǎn)單重復(fù)Sql 可以用MP。復(fù)雜SQL不要用

審核編輯：劉清