為什么還要用mybatis？

這個問題需要真實去使用過，在使用的過程中會發(fā)現(xiàn)各自框架的痛點，當(dāng)你尋找解決方案的時候，你會看其它框架有沒有解決這個問題，這樣你就會領(lǐng)悟到另一個框架的優(yōu)勢了。

分享一個真實的實戰(zhàn)經(jīng)歷：

項目剛開始使用原始JDBC方式操作數(shù)據(jù)庫，自己手動建表不說，手動組裝對象太痛苦，表字段和對象的關(guān)系映射寫一堆代碼，這時候就會想如果有個框架能自動把表和對象關(guān)系自動映射，并且能夠封裝好使用方法，在初始化時還能自動建表就更好了。

查找方案時發(fā)現(xiàn)了SpringDataJpa，仿佛打開了新世界的大門，原來通過寫SQL查詢再轉(zhuǎn)成對象的增刪改查都不用寫了，表字段和對象的映射也不需要手工寫代碼去匹配可，直接使用，而且可以開啟初始化時自動創(chuàng)建數(shù)據(jù)庫表。原來需要消耗時間的數(shù)據(jù)庫操作代碼現(xiàn)在完全不用寫了，簡單的條件查詢，直接調(diào)用封裝的方法，快到起飛。但是隨著業(yè)務(wù)數(shù)據(jù)的不斷增多，要查詢的條件也越來越復(fù)雜，查詢時效越來越慢，漸漸對查詢性能也有了要求。然后就想，在這樣的使用便利上，如果有能便于優(yōu)化數(shù)據(jù)庫查詢性能的解決方案就好了。

再次找解決方案，發(fā)現(xiàn)了MyBatis，感覺發(fā)現(xiàn)了另一個新世界。雖然，它不能直接把表和對象的關(guān)系映射自動封裝好，但是它可以直接把操作結(jié)果映射成需要的對象，只需要建立對應(yīng)的數(shù)據(jù)對象DTO就行，并且多表關(guān)聯(lián)查詢、復(fù)雜條件查詢都可以寫SQL解決，最重要的是SQL和邏輯代碼分析，維護(hù)也很方便，SQL優(yōu)化交給專業(yè)的DBA就行，再次好用到起飛。

突然有一天，公司強(qiáng)制要求數(shù)據(jù)庫從oracle換成MySQL，發(fā)現(xiàn)Mybatis因為都是寫的純SQL，原來的SQL語法是oracle的，現(xiàn)在都要改，太依賴數(shù)據(jù)庫了，不便于換數(shù)據(jù)源。這時想起了不依賴數(shù)據(jù)源的JPA。

總結(jié)一下個人看法：

JPA使用完全面向?qū)ο蟮牡脑O(shè)計思想，一個表就是一個對象，所有的操作直接操作對象就行，方便、快捷，也不需要關(guān)注底層數(shù)據(jù)源問題，但是表之間的關(guān)系復(fù)雜了、查詢復(fù)雜了，這樣的操作不是它的強(qiáng)項。

Mybatis是半面向?qū)ο蟆朊嫦騍QL，SQL與邏輯代碼分離，查詢結(jié)果映射成對象，所有操作上層是對象，下層用SQL，數(shù)據(jù)查詢優(yōu)化上更加實用，因為是寫原生SQL，所以換數(shù)據(jù)源可能麻煩。

還是業(yè)內(nèi)的那句老話，沒有絕對“銀彈”，只有適合當(dāng)前業(yè)務(wù)發(fā)展需要的技術(shù)。