我無法明確的告訴你JPA和MyBatis在國內哪個會更流行，我本人更喜歡JPA，但是我本人日常開發用MyBatis多。

但是我的回答絕對不是在劃水，而是我多年來自己的一點小小的思考。MyBatis用好了就是神！用不好就特么一坨……并且，這個框架只有兩個結果，要么就是用的好，要么就是用不好……

而JPA，用不好，比MyBatis還一坨……但是用好了，那是超越神的存在，因為你已經完全脫離了事務腳本。

有沒有更牛逼的？

有，但是現實中你基本遇不到這樣的大神，因為這樣的大神在成為大神之前，要么早就財務自由了，要么就轉管理了。

國內大多數項目其實根本沒有設計過程，都是想到哪兒寫到哪兒，別說領域模型的設計了，就連OOP都沒有，都是披著OOP的外殼在寫過程。

當然這是大環境所逼迫的，并不是程序員、架構師所能左右的，大環境就很浮躁，就認為一個月能開發出一個支付寶，你沒辦法去抗衡它，大家都要吃飯的嘛，我為什么要打擊別人的夢想呢？只要您給錢，我就盡量滿足您。

我（曾經）非常憤恨這種劣幣驅逐良幣的環境，本來大家都是安心做設計，然后水到渠成的進行開發，客戶也是和和氣氣的跟開發進行商討，結果有些人念歪了敏捷的經，更有甚者，讀了一本《人人都是產品經理》就真的認為自己是個非常牛逼的產品經理了。

都特么一群....

千萬不要自信的認為，前三十年的懶惰，通過一兩本書就能解決自己知識的匱乏。

結果就是導致現在大家都不喜歡靜下心來搞設計，而是喜歡不管三七十二一先沖山頭再說，稍微有點前瞻性的考慮都認為你是過度設計。

你跟他說制定作戰計劃。
毛的的作戰計劃，全都給我上，見招拆招，逢人便打就對了。

仔細一想，好像也沒說錯什么……

但是如果重心放在設計上，那么自然JPA在OOP上比MyBatis優秀太多太多了。

封裝、繼承、多態抽象、接口、實現

一說到OOP，大家都信手拈來，甚至什么貧血模型、充血模型、脹血模型都跟你說的頭頭是道，但是一涉及到實際開發全都拋到腦后去了。

仔細想想，有多久沒有寫類似下面這種代碼了？（隨便寫著玩的，Lombok僅為減少代碼行數）

@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Table(name="uaa_account")
@Entity
public class Account {
    /* 狀態 */
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String username;
    private String password;

    /* 構造 */
    private AccountRepository accountRepository;

    public Account(AccountRepository accountRepository) {
        this.accountRepository = accountRepository;
    }    

    /* 行為 */
    public void login(LoginCommand command) {}
    public void register(RegisterCommand command){}

    /* 事件驅動 */
    @PostPersist
    public void emmitEvent() {}
}

再說一個讓很多開發感到恐懼的事情：

public abstract class AbstractDomAIn {
    @Getter
    protected final String attr;

    public AbstractDomain(String attr) {
        this.attr = attr;
    }
}

試問一下，你有多久沒有寫抽象類和受保護的狀態了？final 這個關鍵字，如果沒有Sonar，大家是不是快把它給忘記了？

只讀屬性究竟意味著什么還記得嗎？
Collections.unmodifiableList() 不可變集合到底用來干嘛的？我估計90%的開發都沒用過這個玩意兒吧？

約書亞·布洛克（英語：Joshua J. Bloch，1961年8月28日－），美國著名程序員。他為JAVA平臺設計并實作了許多的功能，曾擔任google的首席Java架構師（Chief Java Architect）。

2001年出版Effective Java，獲得2001年Jolt獎。詹姆斯·高斯林曾表示相當贊賞此書。

大神的代碼隨處可見，你離大神就是那么的近。

SOLID五大原則，你是否已經忘記的一干二凈了？
你的代碼是否只有分層，而沒有模式？
23種設計模式，隨口能說五六個，但是這五六個都用來解決什么問題的，有沒有仔細思考過？

我從2018年開始負責面試，到今年已經接近三年了，期間從HR提交過來自己走眼的簡歷至少兩千份，現場面試差不多有四百人，能把設計模式和面向對象說清楚的，寥寥無幾。

現在大家的重心都是怎么快速的沖鋒，前面三個山頭，也不給你一個具體的目標，反正你給我沖，沖到哪里咱不管，起碼你沖了。

于是我們可以看到99%的代碼結構就是：

Controller - 幾乎沒代碼
Service - 重災區
Utils - 重災區
Entity - 跟VO有啥區別？
Repository 或 MApper 或 Dao - 幾乎沒代碼
Mapper.xml - 證明我是SQL小王子的時候到了
Test - What? 這干嘛的？

Service太重了，隨便翻開一個Service，里面的代碼一大堆。

不信隨手翻一下現有的項目，超過一千行的Service是不是到處都是？

我形容這種開發為豬突式開發。

那么這個時候，MyBatis牛逼的地方就顯現出來了。

幸好還有個Spring框架如果沒有Spring框架，什么OOP，扯犢子呢？抓緊往上懟懟懟懟代碼，懟完拉倒。

框架是為了簡化開發任務，讓你有更多的時間去做程序設計和邏輯架構。所以，哪個會更流行取決于大環境，而不是開發人員。我本人是更喜歡先設計，后開發的。

但是我同樣是一個有同情心的人，我不忍心破壞別人想當一個架構師的夢想，雖然他可能一行代碼都沒寫過，我依然支持他，當然前提是該背的鍋你得背，該我的錢一個子兒都不能少。

說些題外話

我個人有三種開發方式，第一種是前端驅動，第二種是后端驅動（好像說的是廢話……），第三種是數據驅動。

前端驅動顧名思義，就是做一個項目，前端先上，前端根據設計稿和產品文檔實現了UI之后，后端再根據前端UI去設計后臺架構。這么做的好處在于無論是客戶還是開發，都能面向一個具體的頁面進行需求討論和架構設計，最終實現結果不會跑偏。

前端的開發速度是比后端快的，因此在發生需求變動的時候，響應速度也非?？欤瑢嵲谟幸恍┍容^難處理的UI，例如需要Canvas繪圖的地方，通過口頭（或文檔）補充即可。但是這種方式只適合一些面向客戶的小項目，而不是面向產品的項目，就是說客戶要什么就給他什么，他要一匹馬，你就別給他設計一輛車，到時候吃力不討好。