很多人学后端，会把 MyBatis / JPA 当成“查数据库的工具”。
但真正做过系统的人都会发现：
👉 数据库访问，从来不是“查数据”，而是一整套对象持久化体系。

这一篇不讲 API、不讲配置、不写教程。
只做一件事：给后端的数据访问层，立一张清晰的世界观地图。

一、没有 ORM 的时代：人肉对象序列化

在最早期 Java 后端中，程序员是直接通过 JDBC 与数据库交互的：

• 直连数据库驱动
• 手写 SQL
• 手动绑定参数
• 手动从 ResultSet 取值
• 手动 new 对象、set 属性
• 手动控制事务和连接

本质上，每一行代码都在干同一件事：

👉 把“数据库中的一行数据”，翻译成“内存中的一个对象”
👉 把“内存中的一个对象”，拆成“数据库中的一行数据”

这其实就是最原始的人肉版：

对象 ↔ 数据 的序列化 / 反序列化

问题也很快暴露：

• 大量重复劳动
• SQL 零散不可控
• 映射容易出错
• 事务与异常极难规范

👉 ORM 一定会出现，不是因为“想偷懒”，而是因为系统规模不允许继续手工持久化对象。

二、ORM 的本质：数据库版“序列化系统”

ORM 全称：

Object Relational Mapping（对象关系映射）

如果只从字面理解，很容易低估它。

从工程视角看，ORM 的本质是：

👉 一套“面向数据库的序列化系统 + 对象管理运行时”。

就像 JSON 框架负责：

• Java 对象 ↔ JSON 文本

ORM 负责：

• Java 对象 ↔ 数据库表 / 行

它解决的不是“查数据”，而是：

• 类 ↔ 表
• 字段 ↔ 列
• 对象引用 ↔ 外键
• 对象集合 ↔ 多表结构
• 对象变化 ↔ SQL 操作

以及更深层的问题：

• 什么时候发 SQL
• 修改对象，如何自动更新
• 同一个对象如何保持一致
• 事务中对象如何被管理

👉 从这一刻开始，应该把 ORM 看成：
“对象持久化运行时”，而不是“工具库”。

三、第一条路线：MyBatis ——SQL 工程化路线

MyBatis 的定位非常清晰：

👉SQL 工程化框架（SQL Mapper），而不是完整 ORM。

在 MyBatis 中：

• SQL 是中心
• 框架负责 JDBC 封装
• 负责参数绑定、结果映射、动态 SQL
• 不接管对象生命周期

它的核心价值是：

• 把 JDBC 标准化
• 把 SQL 管理工程化
• 把对象映射自动化

但有一个重要前提：

👉MyBatis 极度依赖开发者的数据库能力。

因为：

• SQL 怎么写
• 走不走索引
• Join 怎么设计
• 性能怎么调
• 锁与事务怎么控

全部在开发者手里。

所以 MyBatis 更像：

数据库工程路线

它适合：

• 对数据库性能高度敏感的系统
• 报表 / 统计 / 大查询
• 核心交易与底层系统
• 有较强数据库工程能力的团队

四、第二条路线：JPA / Hibernate ——对象持久化运行时路线

JPA（Hibernate）走的是完全不同的一条路。

它的目标不是“把 SQL 写好”，而是：

👉让程序员只操作对象。

在 JPA 中，开发者面对的是：

user.setName("Tom");

而不是：

update user set name = 'Tom' where id = 1

JPA 在背后引入了一整套运行时机制：

• 持久化上下文（一级缓存）
• 实体状态机
• 自动脏检查
• 延迟加载
• 级联与关系管理
• 自动 flush

这意味着：

• JPA 封装的不只是 JDBC
• 而是“对象如何存在于数据库中”的完整体系

👉 它更像一个：
数据库版的对象运行时系统。

也正因为如此：

• 封装更多
• 学习成本更高
• 行为不直观
• 但更不容易写错系统

它非常适合：

• 常规业务系统
• 一般复杂项目
• 以领域建模为核心的系统
• 强一致性场景

五、两条路线的本质差异

很多争论，来自一个错误前提：

❌ 谁更高级
❌ 谁更适合大厂

真正的区别是：系统哲学不同。

一句话总结：

MyBatis 更像“数据库工程”，
JPA 更像“业务建模系统”。

六、后端持久化体系全景图

从架构角度，后端数据层应当这样理解：

业务对象（User / Order / Account） ↓ Repository / DAO 抽象层 ↓ ORM / Mapper 框架（JPA / MyBatis） ↓ JDBC（数据库访问规范） ↓ MySQL（存储引擎 / 事务引擎） ↓ 磁盘

这里：

• MySQL 负责：存储、索引、事务、执行
• JDBC 负责：连接与协议
• ORM 负责：翻译与对象管理
• Repository 负责：业务语义边界

👉 ORM 永远是基础设施层，而不是业务层。

七、本课真正要建立的认知

这一篇，你不需要记 API，但必须形成几个判断：

1. ORM 是对象持久化体系
2. MyBatis 是 SQL 路线
3. JPA 是对象运行时路线
4. MyBatis 放大数据库能力，也放大风险
5. JPA 封装复杂度，也隐藏复杂度

你以后遇到的：

• Redis
• ES
• MQ
• 分库分表

本质上都是：

👉对象如何跨介质存在的问题。

八、第六课系列结构预告

这一篇是“地图”。

后面的子篇将逐个拆解：

• 6.1 从 JDBC 到 MyBatis：SQL 工程化是如何发生的？

• 6.2 JPA 的核心到底是什么？——Persistence Context 与对象状态机

• 6.3 ORM 为什么一定会有坑？——从 N+1 到事务错觉

• 6.4 企业真实选型：MyBatis / JPA / 混合架构