flowchart LR
N0["01 连接与 SQL"]
N1["02 MyBatis 映射"]
N2["03 JPA 实体模型"]
N3["04 事务边界"]
N4["05 数据迁移"]
N5["06 选型与验证"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
数据访问与事务
现代 Java Backend Engineering 学习路线：数据访问与事务
0 子目录7 文档
CHAPTER OVERVIEW · 章节概览
先理解连接和 SQL 执行，再比较映射与实体模型；事务边界、迁移和技术选择必须围绕实际业务。
本章学习路线
箭头表示建议的学习顺序；先理解问题，再逐步进入实现与实践。
按顺序学习
7数据访问与 ORM：从零开始的阶段导学数据库访问框架省掉了不少重复代码，但连接、SQL 和事务依然存在。这一阶段沿着一次读写操作，比较 MyBatis 与 JPA 分别接管了什么。遇到性能或一致性问题时，仍要能回到实际 SQL 和事务上检查。MyBatis：映射、动态 SQL、插件与工程边界你已经知道想执行哪条 SQL，只是不想反复写参数绑定和结果集转换，MyBatis 就适合从这里理解。先看一个 Mapper 方法怎样对应 SQL，再学动态条件和缓存，始终保留查看实际语句的习惯。JPA、Hibernate 与 Spring Data：实体状态、映射和查询调用 save 或修改实体字段时，数据库未必就在那一行立刻更新。理解实体状态、持久化上下文和 flush，才能读懂 JPA 程序。下面也会区分规范、Hibernate 实现和 Spring Data 仓库，避免把三者混叫成一个东西。连接池、事务、数据库迁移与数据访问技术决策即使 SQL 写对了，连接耗尽、事务过长或迁移顺序错误，仍会让数据访问出问题。本章把这些容易被框架教程略过的部分串起来：先确定连接和事务怎样使用，再安排结构变更与运行观察。MyBatis-Plus 工程实践MyBatis-Plus 可以减少常见增删改查的样板代码，但生成 SQL 仍然要在真实表和索引上执行。先用它完成简单查询，再查看实际语句；遇到复杂条件时，回到显式 SQL 并不代表使用失败。JDBC vs MyBatis vs JPA：按问题选择数据访问方式如果正在为项目选择数据访问方式，不妨先看几个实际需求：查询有多复杂，是否需要管理对象关系，团队是否愿意直接维护 SQL？下面比较 JDBC、MyBatis 和 JPA 的取舍，而不是按抽象层越高越好来排序。数据访问与 ORM推荐阅读如果 JDBC 的连接、参数和结果集还不熟，先回顾它们，再读 Mapper 或 ORM 文档。框架用法会更容易理解，也更容易解释为什么某次查询变多、某个事务没有按预期提交。