2.5 数据访问

2.5 数据访问

本节摘要：接口要读写数据库。本节讲清 Spring Boot 的两种数据访问方式（Spring Data JPA、MyBatis）、配置数据库连接、实体与 Repository 的写法，以及"ORM 帮你省 SQL"的核心理解。

本节导航

阅读完本节，你应当能够：

1. 理解 ORM 的作用
2. 配置数据库连接
3. 用 JPA 写数据访问
4. 理解实体与表映射
5. 完成增删改查

一、问题与直觉

"接口的数据从哪来？"——从数据库来。Spring Boot 的数据访问以 ORM 为主：用 Java 对象（实体）映射数据库表，框架自动生成 SQL。你写"查用户"的方法，框架翻译成"SELECT * FROM users"——省掉手写 SQL 的麻烦。

二、核心原理

2.1 ORM 映射

实体类 ↔ 数据库表：字段对字段、对象对行。操作对象就是操作数据。

2.2 数据访问层写法

@Entity
public class User {
    @Id
    private Long id;
    private String name;
    // 字段 ↔ 表列
}

public interface UserRepository extends JpaRepository<User, Long> {
    // 继承即拥有 CRUD 方法
}
​

💡 关键直觉：JpaRepository 是"免费的 CRUD"——继承它，增删改查方法全有了，你只需要加"自定义查询"。

三、工程实践要点

3.1 配置数据库

# application.properties
spring.datasource.url=jdbc:mysql://localhost:3306/demo
spring.datasource.username=root
spring.datasource.password=***
​

3.2 JPA vs MyBatis

⚠️ 常见坑：实体字段与表列不匹配。字段名、类型、主键配置必须对应——报"列不存在"先查映射关系。

3.3 练习建议

建一张 user 表
写实体 + Repository
用 Service 调 Repository
接口返回数据
​

一节小结

• 要点一：ORM = 对象 ↔ 表映射
• 要点二：JpaRepository 提供免费 CRUD
• 要点三：配置数据库连接在配置文件
• 要点四：JPA 快速、MyBatis 可控
• 要点五：字段映射是常见坑
• 要点六：接口 → Service → Repository → 数据库

数据通了，最后一节上线——配置与部署。

常见疑问

Q1：JPA 和 MyBatis 到底怎么选？

一句话：JPA 快，MyBatis 可控。JPA（Spring Data JPA）让你定义一个接口继承 JpaRepository 就自动拥有全套增删改查，开发效率最高，适合 CRUD 为主的业务系统；MyBatis 让你手写 SQL、掌控每一条查询，适合查询复杂、需要精细控制 SQL 的场景（比如报表、多表复杂联查）。如果团队用 Java 且是常规业务系统，从 JPA 起步最省事；如果查询非常复杂多变，MyBatis 更灵活。两者也能混用。

Q2：实体类和数据库表是怎么对应的？

映射规则：类名对应表名（默认首字母小写复数形式），类的字段对应表的列，类的实例对应表的一行。用 @Entity 标记实体类，@Id 标记主键字段。Spring Data JPA 会在启动时根据实体自动建表（配置了自动建表策略的话），或由你手动执行迁移。字段名和列名如果不一致，可以用 @Column 注解显式指定——这也是排查"列不存在"报错的突破口。

Q3：继承 JpaRepository 就自动有增删改查，原理是什么？

Spring Data JPA 在启动时会扫描所有继承 Repository 接口的接口，根据接口方法名（比如 findByCity、deleteById）和继承的方法（save、findAll）自动生成实现类。你看到的"免费的 CRUD"其实是一个动态生成的代理对象。理解这点，你就知道为什么自定义查询方法要遵循命名规范——框架按方法名解析出查询条件，名字写错就解析不了，启动就报错。

Q4：数据库连接配置（URL、用户名、密码）为什么要放配置文件？

因为这些信息因环境而异：本地开发连本地数据库，测试环境连测试库，生产环境连生产库，密码还不一样。把配置放 application.properties（配合多环境文件），打包时不用改代码，部署时用对应的配置即可。同时密码这类敏感信息生产环境要走环境变量或密钥服务，别硬编码进代码仓库。

工程实践要点

动手建议：完整实现"实体 + Repository + Service + 接口"的数据链路：建一张 user 表（或用 JPA 自动建表），写实体类，写 Repository，写 Service 调用它，最后在接口里返回查询结果。运行后用接口工具确认数据能正常读写。如果报"表不存在"或"列不存在"，先检查映射关系——类名、字段名、注解是不是都对了。这一步跑通，你就掌握了 Spring Boot 数据访问的完整套路。

实战演练：打通数据链路

本节练习的目标，是把"接口到数据库"的完整链路打通，并且学会排查常见故障。步骤如下：

第一步，准备数据库。在本地建一个测试库，建一张用户表，字段与你将要写的实体类对应（id、name、age）。如果你想让框架自动建表，也可以先不建，让 JPA 根据实体生成。

第二步，写实体类。用注解标记实体、标记主键，字段对应表列。启动应用，确认表结构生成（或已存在）。验收标准：数据库里能看到对应的表。

第三步，写数据访问层接口。让它继承 JpaRepository，泛型指定实体和主键类型。验收标准：不需要写任何实现方法，项目能正常启动——框架已经替你生成了实现。

第四步，在服务层调用数据访问方法，在控制器里暴露接口。访问接口，确认能查出数据。验收标准：接口返回数据库里的真实数据。

第五步，故障演练。故意改错一个字段名（让实体字段与表列不一致），启动后访问接口，观察报错。修复后再试。验收标准：你能从报错信息里读出"映射不匹配"这类线索。

第六步，加分题：用数据访问接口内置的方法实现"按名字查用户"，观察框架是否自动帮你完成了查询——这能验证"方法名约定驱动查询"的机制。

六步走完，你不仅打通了数据链路，还掌握了"映射报错怎么排查"。这是数据访问最重要的实战技能。

一句话记忆

数据访问的完整链路是：实体映射表、数据访问层提供方法、服务层调用、控制器暴露。跑通一次增删改查，再故意弄坏一次映射看报错，你的数据访问就真正会了。