存在這麼一個情況：對於缺營養的人來說，醫生更傾向於建議他選擇純牛奶，而不是有機奶(因其有添加劑)。然而，大部分人卻更加傾向於選擇有機奶，

因其口感不錯，因此，對於選擇純牛奶還是有機奶，這是個博弈問題。

      本篇文章，主要從架構師角度談談為什麼建議選擇mybatis(純牛奶)，而不建議選擇mybatis-plus(有機奶)，大家有任何想法，歡迎在評論區交流。

1  關於dao層技術選型

在JAVA領域，可選擇的ORM框架還是比較多的，如Spring JDBC,JPA,Hibernate,Mybatis,Mybatis-plus等，其中，mybatis可以算得上是領導者，具有極強的領導作用。

2 深入分析mybatis plus插件原理

2.1 資料

//mp.baomidou.com/guide/

//github.com/baomidou/mybatis-plus

2.2 mybatis 源碼架構解析

2.3 mybatis-plus 架構與源碼

3 mybatis plus 存在的問題

關於mybatis-plus的優點，這裡就不論述了，官網說得很詳細，詳細參考官網：

//jiansutech.yuque.com/staff-al4og8/drmyey/brma9c

3.1 增加學習成本

mybatis是公認的，被市場驗證過的，程式設計師普遍認同的，java行業統一認同的ORM框架，但mybatis-plus並未經過市場的充分驗證，且更談不上程式設計師普遍認同

和java行業統一認同，如此，假設A,B,C,D,E,F公司，都用mybatis(因為是公認的，行業默認標準)，而只有A，C公司用mybatis-plus，在這樣情況下，A公司外聘

了B,D,E,F公司的技術人員，這些技術人員加入進來，需要學習mybatis-plus插件，增加了學習成本。

3.2 增加升級和維護成本

1.mybatis版本變化，mybatis-plus版本是否會相應變化?

2.對於mybatis-plus每個版本，是否充分經過市場驗證和證明？若出現不能用或bug，怎麼解決？

3.3 「百花齊放」現象

在Java開發領域，有這麼一個默認共識：在考慮穩定性，可擴展性和生態性前提下，架構越簡單，越單純，越單一，越佳。舉幾個例子：

例子1：架構的乾淨與統一

你會更喜歡一個只有一種ORM還是有多種ORM的框架，除此之外，考慮一下新人入手框架的學習成本以及程式碼的維護成本。

例子2：開發人員的猶豫性

假設開發人員接手一個多種ORM組合的框架，那麼他在開發需求時，他應該選擇哪個ORM框架呢？
例子3：開發人員的排他性

假設一個只熟悉Hibernate的開發人員接手到一個混合ORM框架嗎(暫且定為二混合，即hibernate和mybatis)，當他在開發新需求時，會更傾向於選擇hibernate(即使他

知道，在大多數場景下，mybatis性能優於hibernate性能)，而不是mybatis，當你問他為什麼不用mybatis時，他肯定會反駁幾個讓你無法回對的問題,如框架不是有hibernate

嗎，照著copy不就ok了？我不熟悉mybatis，剛好框架也有hibernate，方便快捷？沒人給我說盡量用mybatis呀，框架有說明么？……

例子4: 開發人員的自我證明與炫耀性

你看現在框架里有多種組合，我也搞一種，A說我封裝了一個Json類，B說我封裝了演算法類，C說我封裝了字元串類,D說公司有自己通用的類，E說你們這些都不行，你看

現在hutool(對該框架感興趣，可參官方文檔：//www.hutool.cn/docs/#/)這麼齊全，直接用就好。。。，如此，真是「百花齊放」，難以控制。

3.4 DB和架構師視角

根據mybatis-plus源碼，隨機抽取幾個功能介面來分析：

1 T selectById(Serializable id);

1.基本性能視角：假設用戶資訊表有100個欄位，100w條數據(其實，100w數據是遠遠不夠的，一般有一定業務量的，都是千萬級別)，每次都SELECT * FROM user_info，結果會怎樣？
2.dba或架構師優化視角：某天，系統很卡，問題回饋到DAB或架構師處，他們均不能直觀的看到sql是怎麼寫的，也沒有時間去研究源碼，也沒時間去反編譯，那麼他們如何去優化？

3.聯合主鍵視角：某天，發現僅僅通過主鍵id不能解決性能問題，需要建立聯合索引，此時，該如何解決？

4.表Join視角：從用戶維度，我們能拆分成很多部分，如用戶基本資訊表(靜態)，用戶資訊表(動態)，用戶組表，用戶資產表，用戶許可權表，用戶部門表，

這些表如何進行join查詢，該如何解決？表的水平垂直拆分，也是相同道理。

5.程式碼評審視角：程式碼評審最重要的是確定程式碼業務邏輯的準確性，其中包括兩部分：(1)程式碼及程式碼邏輯 (2)SQL語句，而mybatis-plus將CRUD封裝在框架內，

無法直接看到SQL，那麼在評審SQL時，如何評審，更恐怖是的是，如果DBA參與評估的話，他看不到SQL，在他那裡評估就過不了。

3.5 安全視角

以用戶資訊表為例，假設該表有100個欄位，其中手機號，身份證，姓名，年齡，資產為其中欄位，現在有個需求：需要開一個介面，統計年齡大於30，

資產100w以上的人id,姓名，手機號，會有什麼樣的問題？

問題一：將不需要的欄位用戶身份證，用戶資產欄位暴露在網路傳輸中，被第三方抓包工具抓取數據，用戶安全資訊存在隱患。

問題二：若進行DTO轉換，是否存在轉換成本，這裡會有兩個性能IO代價，代價一是從DB庫撈取數據成本，成本二是DTO成本。

3.6 不利於架構發展

研究過mybatis-plus源碼的同學知道，這個封裝版框架是將mapper和service捆綁一起的，然而，在微服務架構，中台架構，尤其是DDD驅動設計中，

service和mapper並不是耦合的(否則會造成domain貧血)，對DDD領域感興趣的同學，可以去研究領域驅動設計《實現領域驅動設計 （美）弗農著》，提供DDD簡要架構圖：