知乎高赞：Spring Data JPA 和 MyBatis 谁更强？

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