摘要：朋友们，今天想跟大家聊聊最近一次社招面试中的小插曲。老规矩，先来讲个小故事。
朋友们，今天想跟大家聊聊最近一次社招面试中的小插曲。老规矩，先来讲个小故事。
那天是个星期五，天气晴，阳光灿烂。我拎着背包，心情还不错，毕竟是面试一家我关注很久的公司。
前面聊得都挺顺，什么项目经历、微服务架构、线程池调优都答得很顺。但突然，面试官来了句：
“那你说说，Spring 里的数据访问方式有哪些？分别适用于什么场景？”
兄弟姐妹们，这个问题不难对吧？可我一下脑袋空了。什么JDBC、MyBatis、JPA、Spring Data JPA，全混在一起。
我努力挤出几个关键词：“MyBatis... Spring Data JPA... Hibernate... JDBC Template...”但一说细节，我发现自己原来对这个模块了解远没有想象的扎实。
面试官微笑地看着我：“要不要我们一起来梳理下？”
我点点头，其实内心疯狂报警：完了完了！
于是，在面试官的引导下，我从“尴尬答题”变成了“灵魂补课”。也正是这次“翻车”，让我之后花了三天时间，把Spring的数据访问体系吃了个透。
所以今天，就把这次学习成果整理出来，分享给你们——也许下一次，这道题你就答得比我还漂亮！
我们先来从一个“全景图”开始，看看 Spring 是怎么帮我们一层层抽象数据访问的：
简单点说，这些技术各有优劣，关键是——你要知道它们的适用场景，以及你用的是哪种“高度”的抽象。
一句话对比：
第一步：JDBC 是什么？为什么大家不爱用它？
“你有用 JDBC 写过 DAO 吗？” 面试官问。
我想了想，大一那会儿写过个图书管理系统，自己写 Connection、Statement、ResultSet，还得自己处理关闭连接，麻烦到吐血。
JDBC 的问题：
重复代码多SQL 写在代码里，维护麻烦异常处理太繁琐没有事务管理所以，Spring 的大佬们就出了个封装版本——Spring JDBC。
我记得我很喜欢 JdbcTemplate，因为它把“模板代码”都帮你写好了，比如连接、异常处理、关闭资源。
是不是清爽多了？
简单项目明确 SQL 写法对 ORM 没那么强需求的系统确实。我自己项目中 MyBatis 用得最多——它不搞自动 SQL，也不完全 ORM，但提供了很灵活的 SQL + 映射机制。
最典型的配置是：
或者注解方式：
MyBatis 的优势：
自己写 SQL，灵活支持复杂查询、多表联查配置合理可维护性强缺点嘛：
所以，如果你希望控制 SQL，但不想陷入 JDBC 的泥潭，MyBatis 非常适合！
到这一步，我心里有点发虚——因为 JPA 和 Hibernate 总是搞混。
面试官说：
“其实 Hibernate 是实现，JPA 是接口。”
我突然明白了！
JPA（Java Persistence API）：是一套标准接口，规定了 ORM 应该长啥样Hibernate：是最早最成熟的 JPA 实现之一用个类比：
JPA 是“汽车驾驶标准”Hibernate 是“具体品牌”我们来看个 JPA 的例子：
然后通过 EntityManager 来操作：
JPA 适合：
ORM 场景强实体类和数据库表强耦合没问题想写得“优雅、声明式”但它也有：
“你见过 @Repository 接口不用写实现类的例子吗？”
这简直神了——连 SQL 都不用写，Spring 帮你自动实现！
背后机制是“方法命名约定”，比如：
findByXxxdeleteByYyycountByZzz优点：
快速开发适合CRUD项目、原型项目对 JPA 很熟悉时效率极高缺点：
SQL 不可控联表复杂时力不从心黑盒逻辑不透明朋友们，我想说：
面试中问“Spring数据访问有哪些方式”，不是想考你记得几个框架，而是想看：
你用过哪几个？
各自适合什么场景？
如果让我选，我怎么选？
我面完这家公司后，花了三天时间画了这样一张选择建议图：
Spring数据访问技术选型参考图：
回头看那场面试，我其实挺感激那个面试官的。
他没有直接“否掉我”，而是带着我，一步一步把我知识体系中最松散的一块补起来。
所以今天这篇文章，就送给准备面试的你、或者像我一样正在“补课”的你。
来源：泽拓教育