【译】从JDBC 到 JPA，中间到底发生了什么？转载
在软件开发领域，你喜欢哪些个首字母缩略词？
对于Java-apps-talking-to-database呢？你又喜欢用什么？。
其他人都在使用JPA吗？我应该吗？但我听说了Spring Data JDBC？Spring Data JPA呢？
在本文中，我们将理一下JDBC、JPA、它们来自哪里以及存在的权衡。
很久以前，出现了JDBC
JDBC是Java数据库连接API。这是一个古老的标准，可以追溯到1997年的Java 1.1时代。这个API对我们很有帮助。
一切，我的意思是，与数据库交谈的所有内容都通过JDBC。这有其利弊。基本上，JDBC是所有技术都玩过的所有与数据库交互的标准舞蹈的Java实现。
- 打开连接。
- 打开光标。
- 提交查询。
- 迭代结果集。
- 关闭结果集/光标。
- 紧密连接。
我们可能都遭受了实施20个查询的命运，并在此过程中忘记了关闭其中一个资源。然后，六周后，得到了一个可怕的堆栈跟踪，因为不知何故，我们的数据库没有连接或光标了。
我们追踪这个问题。修补它。释放它。
然后八周后，我们找到了另一个。当我们陷入困境来管理一些不应该那么难管理的事情时，就会发生这种情况。
Spring看到了这一点，并注意到了这一点。Spring Framework以其最受欢迎和最强大的编码模式之一，发布了JdbcTemplate。一个模板，基本上允许您专注于提交查询和消耗结果。
所有资源管理都由工具包处理。你再也不会在凌晨3:00接到电话，因为数据库或者你的程序已经爆掉了。
好吧，也许你仍然会接到那些半夜的电话。但不是因为你没有关闭连接！
问题是，一旦你写了两百个查询，这些字符串中的原始功率捕获量就会变得势不可挡。
事实上，一路上，在你对同一个项目对象进行第十三次查询后，你想知道：“为什么Java不能看到类型......然后为我做？”
欢迎来到JPA的先驱希伯纳特。
然后，Hibernate
多年来，我们与其他事物作斗争的两件事包括将表行映射到Java对象，以及关系数据库实现之间的变化。
当移动到Postgres时，我真的需要重写我的甲骨文查询吗？？
有时，是的。因为ANSI SQL规范没有涵盖所有空白。因此，数据库提供商填补了空白。
Hibernate承诺以统一的方式将Java对象连接在一起......如果我们正确地将这些表映射到它们相关的Java类上。它始于XML，但以Java 5注释起飞！
世界以扭曲的速度向前跳跃！
虽然使用SAME查询以中立的方式与地球上的任何数据库引擎交谈真的很酷，但还有其他事情我们并不真正理解。
好吧，有些人看到它来了，但我们大多数人没有。
你永远不会真正逃避关系表映射的概念。没错。仅仅因为你拿起Hibernate并开始使用它，并不意味着你实际上可以停止从关系数据库的角度思考。
对于最简单的查询，是的，你可以。
select i from Item i where i.description like ‘%:partialDescription%’这种查询是直截了当的。这是有道理的。它是通用的。
一旦你启动并运行了东西，冬眠真的让你哼唱。事实上，它非常受欢迎，人们有时提到春天+冬眠和巧克力花生酱。
所以他们把它标准化了。
Hibernate，变成了JPA
JPA是Java持久API（首字母缩略词FTW中的首字母缩略词！）Hibernate成为它的参考实现。今天大多数使用JPA的商店实际上都在使用Hibernate。
JPA是如此深刻，以至于可以说JPA给了你翅膀！
但不可避免的是，我们发现JPA有一个深刻而黑暗的秘密。要么有人告诉我们的事情，要么是我们自己假设的事情。
你永远不会离开关系数据库表的概念。当您编写更复杂、更纠缠、更面向业务的查询时，您发现有时您的Java对象不适合该范式。
你会发现你只是在用SQL知识来交换JPA知识。
这是可能的。事实上，它非常强大。有时，这种力量需要一点帮助，因此创建了Spring Data JPA。
Spring Data JPA可以帮助你进行更简单的查询，并无需与JPA的EntityManager合作太多。
但最终，你必须进入手动编写的JPQL查询。
如果你觉得可以编写一个非常详细、复杂且微调的JPQL查询，然后SOMEHOW自定义SQL输出，那就肤浅了。
你看，在过去，为你的系统写几十个查询是常见的范式。然后，通过DBA反馈和日常体验的魔力，发现哪些查询效率最低下，花费时间太长。通过利用解释计划，您可以看到你的查询是如何浪费时间。
然后，你可以通过以下方式攻击事物：
- 创建更好的索引。
- 确保统计数据正常运行。
- 重写某些连接。
- 停止对所有东西使用UPPER（或LOWER），以避免完整的表格扫描。
- 不要十次加入同一张桌子！（是的，我曾经遇见过这样的观点。）
还有十几种其他战术。你将调整你的查询，可能需要20分钟的东西可以优化为次级查询。这是数据库/应用程序维护课程的标准。
假设你不是用JPA的输出这样做的。
这就是一些人来称的JPA第九圈。
也许这是你的果酱？也许这对你来说很酷？但对许多人来说，这可能是他们嘴里的不好味道。
那么，你能想象Spring Data JDBC在2017年出现时的热情吗？事实上，我的队友Jens在2018年SpringOne会议上的演讲导致房间里挤满了人，渴望听到这个消息。
Spring Data JDBC提供了一种从JPA深渊边缘撤退的方法。相当酷。如果您想了解更多信息，请查看。
Spring Data JBDC试图为你做很多工作。但它并没有做好奥尔·希伯纳特所做的一切。它假设如果你自己处理一点，你可以保留一些纯粹的JDBC允许的活力和活力。在这里，你现在能够查看和理解你的查询。
在这里，你可以根据自己的喜好调整SQL语句。面对现实，必须总是有一定程度的调音才能让事情变得嗡嗡作响。
作为在你那边多处理一点的交换，你可以避免被拉到ORM的La Brea防水石坑！
无论您选择什么（JdbcTemplate、Spring Data JPA、Spring Data JDBC），希望通过更多地了解他们支持他们的基本标准，你可以对什么最适合你的需求做出可靠的选择。
原文作者：Greg L. Turnquist
