我无法明确的告诉你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绘图的地方，通过口头（或文档）补充即可。但是这种方式只适合一些面向客户的小项目，而不是面向产品的项目，就是说客户要什么就给他什么，他要一匹马，你就别给他设计一辆车，到时候吃力不讨好。

这种类型的项目，MyBatis最合适。

如果一个项目非常大，例如从头开始设计一个B2B的交易平台（包括后台ERP）产品，就不能采用这种方式。

因为采用这种方式的坏处在于他不能站在高处俯瞰全貌，都是一点一点的往上堆砌，就是大家常说的摸着石头过河，最终会导致抽象不足，代码冗余，重构成本高，维护成本高，数据孤岛严重，子系统甚至是子模块业务互斥，向着恶性循环发展，最终项目变得越来越庞杂，无数的内耗产生。

大的项目，一定要从数据建模开始设计，一定是后端驱动，要认真仔细的思考每一个细节，先做抽象设计，然后具象到模块，再由模块具象到每一个实体、接口。

当这一切都设计好了之后，开始模拟数据流转，注意，此时还没有开始写一行代码。

数据流转通畅之后，剩下的编码只是水到渠成的事情，编码过程根本不重要。而这么做，JPA是最合适的。

但是，大部分土老帽认为程序设计是一件很low bee的事情，别笑，真事儿，因为他们认为不需要你来设计，他们自己就能设计好，你所要做的就是把他们“设计”好的东西用代码实现就好了。

他们最喜欢听的一句话就是：

嗯！老板说得对，小的马上就去写代码！

而不是：

老板，我觉得这个地方需要重新设计一下。

最后一种，是数据驱动，这种开发方式也很常见，最明显的就是报表以及大部分挂羊头卖狗肉的大数据处理，因为就这些数据，你很难去做后端驱动，你设计的再好，数据就是缺失的你没办法。

所以数据驱动，MyBatis也是比较合适的，JPA可能不太合适。

来源：
zhihu.com/question/317183937/answer/1474629982