第六课：ORM 是什么？——从 JDBC 到 MyBatis / JPA 的一次认知升级
很多人学后端，会把 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 = 1JPA 在背后引入了一整套运行时机制：
- 持久化上下文（一级缓存）
- 实体状态机
- 自动脏检查
- 延迟加载
- 级联与关系管理
- 自动 flush
这意味着：
- JPA 封装的不只是 JDBC
- 而是“对象如何存在于数据库中”的完整体系
👉 它更像一个：
数据库版的对象运行时系统。
也正因为如此：
- 封装更多
- 学习成本更高
- 行为不直观
- 但更不容易写错系统
它非常适合：
- 常规业务系统
- 一般复杂项目
- 以领域建模为核心的系统
- 强一致性场景
五、两条路线的本质差异
很多争论，来自一个错误前提：
❌ 谁更高级
❌ 谁更适合大厂
真正的区别是：系统哲学不同。
| 维度 | MyBatis | JPA |
|---|---|---|
| 控制中心 | SQL | 对象 |
| 依赖能力 | 数据库能力 | 建模与框架理解 |
| 封装层级 | JDBC 层 | 对象运行时 |
| 出错概率 | 高（人为） | 低（框架兜底） |
| 核心优势 | 性能可控 | 一致性与效率 |
| 常见场景 | 核心/复杂查询 | 普通/业务系统 |
一句话总结：
MyBatis 更像“数据库工程”，
JPA 更像“业务建模系统”。
六、后端持久化体系全景图
从架构角度，后端数据层应当这样理解：
业务对象（User / Order / Account） ↓ Repository / DAO 抽象层 ↓ ORM / Mapper 框架（JPA / MyBatis） ↓ JDBC（数据库访问规范） ↓ MySQL（存储引擎 / 事务引擎） ↓ 磁盘这里：
- MySQL 负责：存储、索引、事务、执行
- JDBC 负责：连接与协议
- ORM 负责：翻译与对象管理
- Repository 负责：业务语义边界
👉 ORM 永远是基础设施层，而不是业务层。
七、本课真正要建立的认知
这一篇，你不需要记 API，但必须形成几个判断：
- ORM 是对象持久化体系
- MyBatis 是 SQL 路线
- JPA 是对象运行时路线
- MyBatis 放大数据库能力，也放大风险
- JPA 封装复杂度，也隐藏复杂度
你以后遇到的：
- Redis
- ES
- MQ
- 分库分表
本质上都是：
👉对象如何跨介质存在的问题。
八、第六课系列结构预告
这一篇是“地图”。
后面的子篇将逐个拆解：
6.1 从 JDBC 到 MyBatis：SQL 工程化是如何发生的？
6.2 JPA 的核心到底是什么？——Persistence Context 与对象状态机
6.3 ORM 为什么一定会有坑？——从 N+1 到事务错觉
6.4 企业真实选型：MyBatis / JPA / 混合架构