知乎高赞：Spring Data JPA 和 MyBatis 谁更强？ | 芋道源码 —

阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 zhihu.com/question/317183937/answer/1474629982 「柳风」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

我无法明确的告诉你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可能不太合适。