作者：糊塗碼 鏈接：https://juejin.cn/post/7156428078061895710 前言 MP 從出現就一直有爭議 感覺一直 都存在兩種聲音 like： 很方便啊 通過函數自動拼接Sql 不需要去XML 再去使用標簽 之前一分鐘寫好的Sql 現在一秒鐘就能寫好 簡直不要太方便 ...
作者：糊塗碼
鏈接：https://juejin.cn/post/7156428078061895710
前言
MP 從出現就一直有爭議 感覺一直 都存在兩種聲音
like：
很方便啊 通過函數自動拼接Sql 不需要去XML 再去使用標簽 之前一分鐘寫好的Sql 現在一秒鐘就能寫好 簡直不要太方便
dislike：
侵入Service層 不好維護 可讀性差 代碼耦合 效率不行 sql優化比較難
之前也有前輩說少用MP 理由就是不好維護 但是這個東西真的是方便 只要不是強制不讓用 就還是會去使用 存在集合里 最近也確實有一些體會 就從兩個角度去看一下MP。
推薦一個開源免費的 Spring Boot 實戰項目：
優點
操作簡潔
就從我們編碼中最常用的增刪改查去說
按照我們之前去使用Mybatis的喜歡我們就要去建立一個XML文件 去編寫Sql語句 算是半自動 我們可以直接去操控Sql語句 但是會比較麻煩 很多簡單的數據查詢我們都要去寫一個標簽 感覺這種沒有意義的操作還是比較煩的 那麼MP裡面怎麼實現。
第一種： 最簡單我們就是直接去使用提供的方法 我們非常簡單就能做到這些操作 但是這個就有一個問題
nodeMapper.selectById(1);
nodeMapper.deleteById(2);
nodeMapper.updateById(new Node());
nodeMapper.insert(new Node());
維護性差 以查詢為例 這個預設提供的方法都是查詢所有欄位我們都知道在編寫Sql的時候第一條優化準則就是不要使用Select * 因為這種寫法是很Low
這個就是上面selectById執行的結果
SELECT Id,name,pid FROM node WHERE Id=?
這種Sql 肯定是不好的所以我們在使用MP的時候儘量不要去使用自帶的快捷查詢 我們可以去使用它裡面的構造器
nodeMapper.selectOne(new QueryWrapper<Node>().eq("id",1).select("id"));
這彙總寫法 我們可以通過後面的select（） 去指定我們需要查詢的欄位 算是解決上面那個問題嗎 但是這個就完事了嗎？ 這還有一個問題。
我們在開發中經常會說一個叫魔法值的東西
//這個就是魔法值
if ("變成派大星".equals(node.getName())){
System.out.println("魔法值");
}
之所以不要多用魔法值就是為了後期維護 我們建議使用枚舉 或者建一個常量類 通過Static final修飾
上面那段代碼是不是也有同樣問題 "id"算不算魔法值呢 這種構造器產生的問題就是 不好維護
假設 我們的這Node類是高度使用的 我們到處都在寫
nodeMapper.selectOne(new QueryWrapper<Node>().eq("id",1).select("id"));
剛開始沒事 我們樂呵呵的 但是一旦我去修改Id 的欄位名怎麼辦
我修改成test（資料庫同步修改） 現在這個實體類中沒有這個欄位 我們再去看我們的代碼
沒有什麼反應 沒有給我提示報錯 我這個時候去運行怎麼辦 我要一個個去找這個錯誤嗎 這明顯很費時間
這個確實是一個問題 但是也是可以解決的
Node node = nodeMapper.selectOne(new LambdaQueryWrapper<Node>().eq(Node::getId, 1).select(Node::getId));
上面這種代碼就可以去解決這個問題 我們在使用的時候可以多用這個東西
一旦修改欄位就會立馬報錯
但是 這就萬事大吉了嗎 NO No NO 我們要是處理稍微複雜的語句怎麼辦？ 比如如我們欄位求和 這個LambdaQueryWrapper還是存在限制的
如果我們想實現這種 怎麼去做呢
select SUM(price_count) from bla_order_data LIMIT 100
首先這種寫法肯定是不太行的 編譯不通過
除非去使用QueryWrapper
還有就是分頁查詢
// 條件查詢
LambdaQueryWrapper<UserInfo> queryWrapper = new LambdaQueryWrapper<>();
queryWrapper.eq(UserInfo::getAge, 20);
// 分頁對象
Page<UserInfo> queryPage = new Page<>(page, limit);
// 分頁查詢
IPage<UserInfo> iPage = userInfoMapper.selectPage(queryPage , queryWrapper);
// 數據總數
Long total = iPage.getTotal();
// 集合數據
List<UserInfo> list = iPage.getRecords();
這個還是非常簡單的
簡單總結
MP 在做一些簡單的單表查詢可以去使用但是對於一些複雜的SQl操作還是不要用
1、SQL侵入Service 的問題我們可以仿照 Mybatis 建一個專門存放 MP查詢的包
2、關於維護性 我們可以儘量去使用 LambdaQueryWrapper 去構造
3、MP是有內置的主鍵生成策略
4、內置分頁插件：基於 Mybatis 物理分頁，開發者無需關心具體操作，配置好插件之後，寫分頁等同於普通List查詢。
缺點
我就說一個最大的缺點就是對於複雜Sql 的操作性很不舒服 比如我們去多表查詢 你怎麼去寫呢
看一個例子
就是通過
@Select 註解
將Mp的查詢條件嵌入進去
${ew.customSqlSegment}
咱就是一整個大問號 聯表老老實實去寫XML吧 這種真的不要去用 太醜了
總結
沒有過多的東西 基本都是最近看到的東西
1、複雜語句不推薦使用MP 能用最好也別用 可讀性差 難維護 使用剛開始沒感覺 後期業務擴充 真的噁心的
2、可以使用MP中的分頁 比較舒服 逐漸生成策略也舒服
3、儘量不要去使用MP中自帶的selectById 等全表查詢的方法
4、儘量使用LambdaQueryWrapper的書寫形式 至少比較好維護
5、簡單重覆Sql 可以用MP。複雜SQL不要用
完結有想到的會補充各位同僚有其他意見可以評論區見 會補充修正。
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2022最新版)
4.別再寫滿屏的爆爆爆炸類了，試試裝飾器模式，這才是優雅的方式！！
覺得不錯，別忘了隨手點贊+轉發哦！
