Spring 数据访问与数据库整合

企业级开发里，业务代码最终很少能绕开数据库访问，但真正的问题从来不只是“会不会写 SQL”。

数据访问这一条线真正要解决的是：

1. 应用如何连接数据库
2. SQL、事务、映射、连接池这些能力如何组织
3. JdbcTemplate、MyBatis、JPA 这些方案分别适合什么场景
4. Spring 到底在数据库访问里提供了哪些统一能力

这篇文章主要负责建立一张总览图，把后续 MyBatis、事务、连接池、ORM 等专题串起来。

---

1. Spring 为什么要管数据访问

如果没有统一框架，数据库访问代码很容易散成这样：

1. 到处自己获取连接
2. 到处自己写提交和回滚
3. SQL 执行和业务逻辑强耦合
4. 异常处理风格不统一

Spring 在这里主要做两件事：

1. 把数据访问的公共能力统一起来
2. 把事务、连接、异常转换这些横切问题从业务代码里抽出去

所以 Spring 管数据访问，不是为了替你发明数据库，而是为了把数据库访问从零散低层操作收口成可维护的应用层模型。

---

2. 一条完整的数据访问链路通常包含什么

如果把企业应用里的数据库访问压缩成一条完整链路，通常会包括：

1. 数据源 DataSource
2. 连接池
3. 数据访问框架
4. 事务管理
5. 异常转换
6. 领域对象或 DTO 映射

一次数据库访问，不只是“发一条 SQL”，而是连接、执行、映射、事务、异常、资源释放这一整套动作的组合。

---

3. DataSource 到底是什么

DataSource 可以理解成应用访问数据库连接的统一入口。

它解决的是：业务代码不要自己到处 new 连接，而要通过一个统一资源入口拿连接。

在 Spring 语境里，很多数据库访问能力最后都会建立在 DataSource 之上。

---

4. 连接池为什么属于数据访问主线

因为企业应用里几乎不可能每次访问数据库都现建现关一个连接。

连接池解决的是：把数据库连接复用起来，避免频繁创建销毁连接带来的成本和抖动。

所以数据访问这条线里，一个很常见的基础组合就是：

1. DataSource
2. 连接池
3. 事务管理器
4. 上层数据访问框架

---

5. Spring 常见的数据访问方式有哪些

在 Spring 生态里，最常见的几种方式通常是：

1. JdbcTemplate
2. MyBatis
3. JPA / Hibernate
4. Spring Data 系列

它们不是简单的“新旧替代关系”，而是对 SQL 控制力、开发效率和对象映射抽象程度不同。

5.1 JdbcTemplate

它更适合保留 SQL 控制力，同时减少原始 JDBC 的模板代码。

5.2 MyBatis

它更适合希望自己掌控 SQL，但又不想手写太多 JDBC 样板代码。

5.3 JPA / Hibernate

它更适合更偏对象模型驱动，希望由 ORM 帮你管理实体映射和常见持久化操作。

---

6. JdbcTemplate 到底解决什么问题

原始 JDBC 最大的问题之一，是模板代码太重：

1. 获取连接
2. 创建语句
3. 执行 SQL
4. 遍历结果集
5. 关闭资源

JdbcTemplate 的价值在于：把这些重复模板动作收口，让你更聚焦 SQL 和结果处理。

例如：

@Repository
public class UserJdbcRepository {

    private final JdbcTemplate jdbcTemplate;

    public UserJdbcRepository(JdbcTemplate jdbcTemplate) {
        this.jdbcTemplate = jdbcTemplate;
    }

    public User findById(Long id) {
        return jdbcTemplate.queryForObject(
                "select id, name from user where id = ?",
                (rs, rowNum) -> new User(rs.getLong("id"), rs.getString("name")),
                id);
    }
}

---

7. 为什么很多项目会在 MyBatis 和 JPA 之间纠结

因为它们代表的是两种很不一样的思路。

7.1 MyBatis

核心特点是：SQL 由开发者自己掌控。

适合 SQL 较复杂、对查询控制要求高的场景。

7.2 JPA

核心特点是：更强调实体模型和对象关系映射。

适合标准增删改查较多、希望提升通用开发效率的场景。

1. MyBatis 更偏 SQL 驱动
2. JPA 更偏对象模型驱动

---

8. Spring 在数据访问里提供了哪些统一能力

这部分一定要单独讲清楚。

Spring 不同数据访问框架之上，常见的统一能力主要包括：

1. 数据源管理
2. 事务管理
3. 异常转换
4. 依赖注入与配置整合

8.1 事务管理

这是最核心的一条。

无论底层是 JdbcTemplate、MyBatis 还是 JPA，Spring 都能把事务边界统一收口到应用层。

8.2 异常转换

Spring 会把很多底层数据访问异常转换成更统一的异常体系，便于上层统一处理。

8.3 配置整合

通过 Spring Boot，很多数据源、事务和访问框架的接入会更简单。

---

9. 数据访问相关常见注解和组件

注解 / 组件	作用
@Repository	标记数据访问层组件
@Transactional	声明事务边界
DataSource	统一数据库连接入口
JdbcTemplate	简化 JDBC 模板代码
PlatformTransactionManager	统一事务管理抽象

例如：

@Repository
public class OrderRepository {

    private final JdbcTemplate jdbcTemplate;

    public OrderRepository(JdbcTemplate jdbcTemplate) {
        this.jdbcTemplate = jdbcTemplate;
    }

    public int updateStatus(Long id, String status) {
        return jdbcTemplate.update(
                "update orders set status = ? where id = ?",
                status, id);
    }
}

---

10. 企业里最常见的数据访问组合长什么样

比较常见的组合通常是：

1. Spring Boot + HikariCP + MyBatis
2. Spring Boot + HikariCP + JPA
3. Spring Boot + JdbcTemplate

为什么会有这些组合？

因为企业应用真正要做的，不是只选一个技术名词，而是把：

1. 连接池
2. 数据访问框架
3. 事务管理
4. 配置管理

这几件事一起拼成一套稳定方案。

---

11. 工程上最容易混的几个边界

11.1 误区一：数据访问框架只是在替你发 SQL

不只是。

它还涉及对象映射、异常处理、资源管理和与事务的协同。

11.2 误区二：只要有 ORM，就不需要理解 SQL

不是。

企业场景里性能、索引、复杂查询、批量写入这些问题，仍然离不开 SQL 基础。

11.3 误区三：连接池、事务、ORM 是三个不相关的话题

它们在真实应用里是紧密耦合的一条链路。

---

12. 推荐继续阅读

从这篇继续往下读，比较自然的顺序通常是：

1. 看 Spring 事务详解
2. 再看 MyBatis
3. 再结合 MySQL 里的连接池、并发读写和 SQL 场景专题一起理解

---

13. 一句话总结

Spring 数据访问这条线，本质上是在解决应用如何以统一方式组织数据源、连接池、事务、SQL 执行和对象映射；而企业开发里真正关键的，不是只选某个框架名，而是把这整条链路设计稳。