選擇MyBatis還是JPA

這篇文章將為大家詳細講解有關選擇MyBatis還是JPA，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

我扔掉了JPA

我仔細想了一下，有下面幾點原因，造成了JPA在很多團隊根本就玩不下去。

1. JPA適合業務模型固定的場景，適合比較穩定的需求。但是國內這種朝三暮四的需求風格，產品經理這種傳話筒式的設計模式，造成了需求的泛濫和不確定。JPA在這種模式下就是渣。

2. JPA的技術要求比較高。不要懷疑，你剛開始用起里可能覺得非常簡單。但隨著你的深入使用，你會發現這是一個災難。里面的各種轉換和緩存，會把人繞暈。而大多數的快餐程序員是不想要了解這些的。

3. 很多程序員很會寫SQL，所以很多SQL語句長的很胖，長的要命。業務混亂，多張表關聯，我甚至見過上百張業務表關聯的復雜業務。DBA無奈之下，通常都會有sql審核。JPA搞sql審核？還是弱了一點。

所以，不是JPA不好，而是它不符合國情而已。想要在公司內推行JPA，你需要給我一個穩定的產品團隊、一個牛X的技術團隊才行。

所以，大多數公司寧可寫一堆重復的、亂七八糟的 MyBatis 代碼，也不會輕易嘗試JPA，這是符合邏輯的，符合事物發展規律的。

所以，我們下面的文章就是來討論 MyBatis 的，來看一下 MyBatis 到底要怎么寫才算優雅。

MyBatis為什么不好用

優秀的程序員都是很懶的。所以很多人不想設計實體的 sql。 JPA 可以直接根據 Java 的實體代碼，生成 sql 的庫表，這在使用 MyBatis 的人來看，是非常羨慕的。

使用MyBatis，要倒著來。需要先設計庫表，然后根據庫表反向生成一堆Java代碼和配置文件。

這個代碼生成器，就是mybatis-generator。

但是，請注意。這個生成器生成的代碼，有四種模式！！！這就是最讓初學者難受的地方。如果你也是剛接觸MyBatis，強烈推薦只關注下面第一種模式。

• MyBatis3 這種模式就是我們常用的方式，會生成domain類、Example類、mapper映射文件等。它生成的信息比較啰嗦，內容幾乎無法改動。對于項目中自己寫的sql，一般都采用手寫的方式再寫一份，而不是改動原來的文件。

• MyBatis3Simple 上面這種模式的簡易代碼生成模式，缺少一些東西，但很簡潔。對MyBatis沒有經驗，不推薦使用它。

• MyBatis3DynamicSql 這是通過Builder模式實現的動態SQL特性，你還需要加入額外的jar包。加上它之后，其實和JPA是有點相似的。既然如此，那為何不直接使用JPA呢？所以這個DSQL雖然是默認的生成行為，但是非常不推薦。

• MyBatis3Kotlin 這個不廢話。就是生成Kotlin版的一些配置和代碼信息。

所以，下面僅僅介紹MyBatis3模式的代碼生成。

要使用它，需要在pom.xml里加入它的依賴。

org.mybatis.generator
    mybatis-generator-core
    true
    test
    1.4.0

我個人喜歡使用 Java 代碼來操作代碼生成這個過程，所以下面就是生成代碼的代碼。

public class MBGTool {
    public static void main(String[] args) throws Exception {
        List warnings = new ArrayList();
        boolean overwrite = true;
        InputStream configFile = MBGTool.class.getResourceAsStream("/generator/generatorConfig.xml");
        ConfigurationParser cp = new ConfigurationParser(warnings);
        Configuration config = cp.parseConfiguration(configFile);
        DefaultShellCallback callback = new DefaultShellCallback(overwrite);
        MyBatisGenerator myBatisGenerator = new MyBatisGenerator(config, callback, warnings);
        myBatisGenerator.generate(null);
    }
}

從代碼中，我們可以看到需要配置一個generatorConfig.xml文件，用來規定怎么生成代碼文件。

        

        

            

            

        

        

        

            

        
        <table tableName="test"/>

運行我們的MBGTool文件之后，就可以生成 MyBatis 的代碼了。

怎么寫代碼最優雅

但是，我這里并不是要推薦你使用這種模式。因為，它生成了一大堆無用的文件。假如你的項目使用了 sonar 這樣的代碼質量審查工具，你會發現很多飄紅的地方，還有那要命的覆蓋率問題。

怎么辦？

經過我多年的摸索，我現在推薦一種非常好用的寫法。自從我采用了這種方式之后，就再也沒有換過。

第一、不需要代碼生成器了

數據表的設計，還有 domain 的書寫，全部靠手工。這樣我們的代碼，如果有必要，還可以遷移到 JPA 上去。這種模式還能順便學習一下 Java 里面的數據類型，是如何和 SQL 里的數據類型一一對應的。在做表設計的時候，順便能夠了解一些背后的原理。

第二、不需要寫映射文件了

生成器生成的東西，確實是有一堆無用的邏輯。比如我的某個數據表，根本不需要提供查詢所有和刪除這種動作，它還是默認提供了。

在這種簡約模式下，我們直接手寫 Mapper 文件，然后只聲明所需要的接口方法就可以了。

@Mapper
public interface AccountBasicMapper {
    @Insert("AccountBasicMapper/insert.sql")
    void insert(@Param("r") AccountBasic record);
}

可以看到，里面有一個 Insert 注解，我們傳入了一個具體的 domain，然后，就可以在AccountBasicMapper目錄下的insert.sql文件里，書寫具體的 sql 語句了。

sql語句樣例如下：

INSERT INTO account_basic(
    account_id,
    nick_name,
    password,
    sex,
    state,
    photo_url,
    created,
    modified,
    version
)VALUES (
    ,
    ,
    ,
    ,
    ,
    ,
    ,
    ,

    
)

那么這是什么語法呢？它又是如何知道是這樣配置的呢？這就需要引入 MyBatis 的腳本語言配置功能。在這里，我們使用的freemark的模版。

不要忘了加入它的依賴。

org.mybatis.scripting
    mybatis-freemarker
    1.2.2

然后，在yaml文件里做上相應的配置就ok了。

mybatis:
  check_config_location: false
  scripting-language-driver:
    freemarker:
      template-file:
        base-dir: mappers/
      path-provider:
        includes-package-path: false
        separate-directory-per-mapper: false

這種方式的好處和壞處

我個人是非常喜歡這種模式的。因為它有下面幾個好處：

1. 用什么寫什么，代碼量少，簡潔優雅。

2. SQL集中，不用分散在代碼里，xml里，或者注解里。方便DBA進行SQL審核。由于沒了xml的干擾，SQL反而更加簡潔了。

3. 一個DAO方法一個sql文件，模式單一可控。

4. MyBatis的功能優勢可以全部發揮，無縫集成。

當然，缺點也是顯而易見的。

1. 即使變了個參數，也要修改很多sql文件。

2. 需要為每一個方法配一個sql文件，即使這是個很弱智的插入查詢方法。

不過，我并不認為這是個問題。每一個方法配備一個sql文件，代碼寫起來反而更加簡單了。當出現問題的時候，也不用根據邏輯進行跟蹤定位到拼接后的 SQL 語句。我現在，只需要拿到對應方法的 SQL 文件，就可以改吧改吧，直接在 sql 終端里執行調試。這樣，sql 優化也變的簡單了。

當然，一個人一個習慣。我個人喜歡這種模式，而且在我的團隊里推行這種模式，發現運行的也很好。另外，程序員為了少寫重復的 sql 代碼，在設計Dao接口的時候，反而更加認真了。

關于“選擇MyBatis還是JPA”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。