Spring Data JPA 入门

1. 一句话简介

Spring Data JPA 是 Spring 官方在 JPA（Java Persistence API，Java 持久化规范）之上的数据访问抽象层，默认以 Hibernate 作为底层实现。它把 Java 对象通过 @Entity、@Table、@Column 等注解映射到关系数据库的表，让开发者以面向对象的方式操作数据库，而不是手写 SQL。

其核心价值在于「零 SQL 的 CRUD」：只要继承 JpaRepository<User, Long> 这样的接口，就能立即获得 save、findById、findAll、分页、排序等一整套开箱即用的方法（对应本模块的 UserDao）。在此基础上，它通过「方法名推导」（如在 DepartmentDao 中声明 findDepartmentsByLevels(Integer level) 即可自动生成 WHERE levels = ? 的 SQL）和 @ManyToMany、@OneToMany 等关联注解，把大量繁琐的数据库访问和对象关系映射逻辑封装起来，让开发重心从「怎么写 SQL」转移到「如何建模领域对象」。

2. 什么时候使用

✅ 适用场景

标准 CRUD 密集的管理系统：如用户、部门、订单等实体的增删改查。继承 JpaRepository 即可完成绝大多数操作，无需编写重复的 SQL（本模块 UserDao 一个空接口就承载了全部 CRUD）。
强对象关系建模的业务：实体之间存在 1:N、N:N、自引用等关系时，JPA 的原生关联注解（@ManyToMany + @JoinTable、@OneToMany/@ManyToOne）能直接建模——本模块用 300 行左右就实现了「用户多对多部门」和「部门自引用树形结构」两类常见关系。
需要统一审计字段的场景：通过 @MappedSuperclass 抽取 id、create_time、last_update_time 到基类，配合 @CreatedDate/@LastModifiedDate 和 @EnableJpaAuditing 自动填充，避免每个实体重复定义这些公共字段。
规范驱动的团队与跨数据库迁移需求：JPA 是 Java EE 标准规范，底层实现可替换（Hibernate、EclipseLink 等），适合希望面向接口编程、未来可能更换数据库或 ORM 实现的团队。

❌ 不适用/需谨慎

复杂报表与复杂动态查询：JPA 在动态拼接、多层 JOIN、子查询方面笨重，需要绕道 @Query、Specification 或原生 SQL，写起来远不如 MyBatis 直接。
SQL 优化要求高的性能敏感场景：JPA 自动生成的 SQL 难以精确控制，EAGER 加载和级联操作容易产生多余的关联查询、N+1 问题，需谨慎配置抓取策略。
表结构频繁变动的场景：若 ddl-auto 使用 update 依赖 Hibernate 自动改表，在大型表上升级可能耗时且有风险；validate 严格校验时表结构一改需同步调整实体，迭代快时成本高。
复杂 SQL 团队或已有大量 SQL 资产的项目：当团队习惯用 SQL 思维、存量复杂 SQL 资产庞大时，平滑迁入的性价比不高。

3. 常见业务场景

基础用户管理：用户实体的注册、查询、启停、删除。本模块的 UserDao 一个接口即可覆盖保存、按 ID 查询、全量查询、分页排序（PageRequest.of(currentPage, pageSize, sort)）等操作，配合 data.sql 预置测试数据，几乎不写一行 SQL。
组织架构/部门层级（自引用树）：部门有上级和下级，Department 实体同时持有 @ManyToOne superior（指向父节点）和 @OneToMany children（子节点集合），天然建模树形层级；配合 findDepartmentsByLevels 按层级查询，适合做部门管理、分类目录等。
多对多基础数据关联：用户与部门的归属关系，通过 User 端 @ManyToMany + @JoinTable(name = "orm_user_dept") 定义中间表，一端维护关系、一端 mappedBy，适合「角色-权限」「学生-课程」等 N:N 场景。
自动审计的时间自动填充：让 create_time、last_update_time 由 JPA 自动管理，业务代码无需手动赋值。适合所有需要留存创建/更新时间的业务表，避免在每处插入、更新逻辑里手工设置时间。

4. 同类技术对比

维度	Spring Data JPA	MyBatis / MyBatis-Plus	JdbcTemplate	Spring Data JDBC
开发效率（CRUD）	高，继承 `JpaRepository` 即得全套	高（MyBatis-Plus 有增强），原生需写 XML	中低，需手写 SQL	高，Repository 抽象，无 JPA 注解
SQL 可控性	低，由 Hibernate 自动生成，微调难	高，SQL 完全手写可精确控制	高，SQL 完全手写	中，倾向约定优于配置
复杂关联建模	强，`@ManyToMany`/`@OneToMany`/自引用原生支持	中，关联需手写查询	弱，需自行组织	弱，无复杂懒加载/级联
学习成本	中上，注解、会话生命周期、懒加载需理解	中（XML 与注解两种写法）	低，直观	低
分布式/分库分表	弱，需配合外部中间件，自动 SQL 难掌控	中，SQL 可控便于分片改写（如 sharding-jdbc）	中，SQL 可控	弱
适用规模	中小型、标准 CRUD、领域模型驱动	中大型、复杂 SQL 与报表、团队 SQL 文化强	轻量任务、少量数据访问	小而精的简单 CRUD

选型建议：以标准 CRUD 和对象关系建模为主、追求开发效率的中小型系统，优先选 Spring Data JPA。需要复杂 SQL、动态查询、精准 SQL 优化或已有大量 SQL 资产时，选 MyBatis/MyBatis-Plus 更顺手。项目数据访问简单、不想引入 ORM 复杂度、采用 Spring 生态时，JdbcTemplate 或 Spring Data JDBC 是更轻的选择；而在需要掌控 SQL 以落地分库分表、水平扩展的中大型系统，MyBatis 类方案的 SQL 可控性优势更明显。