第六课 · 6.1 从 JDBC 到 MyBatis：SQL 工程化是如何发生的？

如果说 ORM 是"对象如何存在于数据库中的体系"，

那 MyBatis，就是这套体系中最靠近数据库的一条工程路线。

这一篇不讲 XML 怎么写，不讲分页插件，不教 CRUD。

我们只回答一个问题：

👉 为什么 JDBC 一定会进化出 MyBatis？

一、JDBC 在干什么？------最原始的数据访问形态

在 JDBC 时代，后端访问数据库，几乎是纯手工劳动：

手写 SQL
手写参数绑定
手写结果映射
手写连接与事务管理

一个最普通的查询，至少包含四类代码：

SQL 拼接
参数处理
执行与异常
对象封装

本质上，每个项目都在重复造这套轮子。

👉 JDBC 从来不是"ORM"，它只是：

数据库通信协议的 Java 封装。

二、JDBC 的真实痛点（不是"麻烦"，是"不可工程化"）

如果只是"代码多"，其实不是大问题。

真正致命的是：JDBC 让 SQL 难以工程化。

典型问题包括：

1️⃣ SQL 分散，无法管理

写在代码里
拼在字符串中
逻辑和业务混在一起

👉 结果：无法复用、无法规范、无法审计。

2️⃣ 映射逻辑高度重复

ResultSet → Object
null 处理
类型转换

👉 每个项目都在造"半吊子 ORM"。

3️⃣ 动态 SQL 不可维护

if 拼字符串
参数错位
SQL 注入风险

👉 可读性、可维护性、可演进性极差。

4️⃣ 数据访问层无法沉淀为"基础设施"

你几乎不可能：

给 JDBC 层统一加审计
统一分页
统一慢 SQL 监控
统一加密/脱敏

👉 因为 JDBC 太原始。

三、MyBatis 出现：不是 ORM，而是"SQL 工程化框架"

MyBatis 的诞生目标非常清晰：

👉 把 JDBC + SQL 这件事，升级为"工程能力"。

它做的核心事情，其实只有四类：

✅ 1. SQL 结构化管理

XML / 注解集中管理
与 Java 接口绑定
形成可治理资产

✅ 2. 参数绑定标准化

#{} 预编译
类型自动转换
安全防注入

✅ 3. 结果映射自动化

ResultMap
驼峰映射
嵌套结构支持

👉 JDBC 时代最大工作量，直接消失。

✅ 4. 动态 SQL 语言化

if / choose / foreach / trim
SQL 从"字符串"，变成"结构语言"

👉 这是 MyBatis 的工程价值核心之一。

四、Mapper 接口：MyBatis 最关键的抽象

MyBatis 真正改变工程形态的，不是 XML，是：

👉 Mapper 接口

java 复制代码

UserMapper.findById(Long id)

这一层的出现，意味着：

数据访问层开始"接口化"
SQL 与业务解耦
Repository 模式自然形成

Mapper 的本质是：

SQL 的"函数签名"。

这一步，让数据库访问第一次具备了：

可替换性
可测试性
可治理性

👉 这是 JDBC 永远做不到的

五、MyBatis 的本质定位（非常重要）

从系统层级看，MyBatis 从来不是完整 ORM。

它没有：

对象生命周期
脏检查
一级缓存体系
关系自动管理

它只关心：

👉 一条 SQL，如何优雅地执行，并把结果翻译成对象。

所以一个非常准确的定位是：

MyBatis 是 SQL Mapper，不是 ORM 引擎。

也正因为如此：

性能路径清晰
行为完全可控
但工程责任在开发者

六、为什么 MyBatis 天然依赖数据库能力

用 MyBatis，本质是把这件事交给你：

SQL 设计权
索引设计权
Join 策略
锁与事务粒度

框架不会替你兜底：

不会防 N+1
不会防慢 SQL
不会自动批量
不会理解业务关系

👉 MyBatis 放大能力，也放大短板。

所以它更适合：

有 DBA / 数据库专家的团队
对性能路径高度敏感的系统
报表、统计、核心链路

七、MyBatis 在真实企业中的位置

在大多数中大型系统里，MyBatis 很少"单独存在"，而是：

作为复杂查询层
作为核心数据通道
作为性能兜底方案

常见结构是：

JPA 管业务对象

MyBatis 管复杂 SQL

👉 MyBatis 往往出现在：

"系统最怕慢、最怕错、最怕炸"的地方。

八、本篇你应该真正带走的认知

这篇不要求你会用 MyBatis，但你必须形成几个判断：

MyBatis 的核心价值是"SQL 工程化"
它解决的是 JDBC 的工程不可控
它不是 ORM 引擎
它要求数据库工程能力
它更像"数据库工程路线"