为什么使用 JPA 而不是使用 JDBC 编写 SQL 查询？

Question

我一直在阅读几篇文章什么是 JPA (Java Persistent API) 以及支持它的供应商（DataNucleus、JBoss Hibernate 等）

我没有 ORM（对象关系映射）方面的经验。

到目前为止，我所做的是使用 DTO 和 DAO 编写自己的数据库类。到目前为止，我对自己拥有的东西很满意，但想知道 为什么人们使用 JPA 而不是包含 SQL 的 Java 文件。

对我来说，我觉得像下面这样编写 DAO 类就可以了。

 public class DAOUsers {
     public void insertNewUser(DTO DtoUser) {
           String query = "INSERT INTO users(username, address) " +
                          "VALUES(DtoUser.username , DtoUser.address)";
           Executor.run(query);
     }

}

我了解到 JPA 使用 JPQL，Java 持久查询语言，它针对实体对象而不是直接使用数据库表进行操作。

我的理解（如果我错了请纠正我）是这里的实体对象与我的 DTO 对象相同（有点像 bean？）

但是无论如何.. JPA 比在我的文件中编写纯 SQL 有什么真正的好处？似乎使用 JPA 所需的注释并使 SQL 不可读对我来说并不是很吸引人。

如果您需要更多说明，请告诉我，我是这个话题的新手，想听听一些意见。

原文由 Meow 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

为什么使用 JPA 而不是直接在 Java 文件上编写 SQL 查询（即直接到 JDBC）？

某些项目要求工程师更多地关注对象模型，而不是用于访问数据存储的实际 SQL 查询。这个问题实际上可以解释为

为什么要使用 ORM 框架？

在不同的上下文中可以有不同的答案。

大多数项目都可以从领域模型中获益，持久性是第二个问题。使用 JPA（实现）或大多数其他 ORM 框架，可以将所有实体（即数据库中的表）建模为 Java 中的类。此外，还可以将行为嵌入到这些类中，从而实现行为丰富的领域模型。此模型中的实体可以有多种用途，包括替换 DTO 以跨层传输数据的用途。

也就是说，有些地方 ORM 框架可能无法直接解决问题，尤其是当数据模型已经建立时，或者当一个人正在使用将数据库表映射到 Java 类的遗留系统时。在某些情况下，如果需要绝对调整 ORM 框架生成的 SQL，那么 ORM 框架通常不适合。

相关问题

1. Java EE 架构 - 在使用像 JPA 2 这样的 ORM 时是否仍然推荐使用 DAO？
2. 使用 ORM 还是纯 SQL？
3. ORM 与手写数据访问层

原文由 Vineet Reynolds 发布，翻译遵循 CC BY-SA 3.0 许可协议

Answer 2

虽然这是一个老问题，但我觉得它应该得到一个新的答案。我是 JPA 的较晚采用者，我断断续续地使用了几年，虽然我曾经对建立新应用程序的简单性印象深刻，但我已经完全不为所动了具有正确执行 JPA 所需的性能、复杂性和学习曲线。该线程中的答案实际上强化了我的立场。

首先，@vineet 建议“实体可以有多种用途”……我在生产中看到过，我想说这是 ORM 鼓励的。凝聚力和单一责任主体就这么多了。根据我的经验，向数据库实体添加行为是自找麻烦。我知道这一点，因为我已经做到了，并且为之后悔。

其次，对于 JPA 的复杂性，有一些简单的替代方法，这些方法提供了将类与 RDBMS 一起使用的能力，而没有 ORM 试图（未成功）解决的不匹配导致的所有繁重（和性能问题）。十年来，我们一直在一个拥有 1,000 多个表的应用程序中使用非 JPA 关系类映射工具，我们根本看不出 JPA 与更直接的数据库访问相比有何改进。 JPA 在向类模型添加开销（以注释和 JQL 的形式）的同时掩盖了数据库的强大功能……它不应该以其他方式工作吗？

@water 提出了许多理论上正确但在现实中不切实际的事情。例如，切换后端数据库 3 次后，我可以向读者保证，不存在一些配置调整这样的事情，您就大功告成了。我建议，如果您花费大量时间维护您的持久层，您的数据库模型正在发展，并且您将在 JPA 中做相同或更多的工作。特别是当 JPA 中的非平凡查询需要使用 JQL 时！

几乎每个人都假装 JPA 开发人员不需要了解 SQL。我在实践中看到的是，现在我们必须学习 SQL 和 JQL。显然我们不必做 DDL——但在任何重要的应用程序 中，你当然 需要了解 DDL。 Hibernate 甚至不推荐使用自动 DDL 生成。显然我们不必做 DML，除非我们调用本机查询，这当然是不可移植的，粉碎缓存，并且具有与 JDBC 相同的所有问题……

最终，在领域模型独立于业务逻辑的结构合理的应用程序中，JPA 提供的功能很少，我发现这是一个非常高的学习曲线——因为领域模型实际上非常容易构建.我不会直接使用 JDBC，但是像 Apache DBUtils 这样的东西在 JDBC 之上提供了一个简单的层，将行映射到对象，并且稍加努力就可以提供 JPA 的大部分优势，没有任何隐藏和开销。

自 JDBC 1.0 以来，我一直在开发 Java 数据库应用程序，使用各种库（以及 JDBC 之前的 iODBC 和 ESQL），并且仅出于性能原因，我不再使用 JPA。但即使性能更好，学习曲线和不完整的抽象也让我严重停顿。 JPA 很复杂，并试图隐藏在我看来，开发人员实际上需要关心的细节。例如，我们最近看到 hibernate 在一个就足够的情况下向数据库发出 250 个删除命令。 JPA，就其本质而言，使这种错误变得容易。

我不是提倡 JDBC，我只是提倡反对 JPA。不会或不能使用 SQL 的开发人员可能不应该编写关系应用程序 - 就像像我这样无法使用矩阵代数来挽救生命的开发人员不应该编写 3D 游戏。确实以 SQL 为生的开发人员应该被休眠发送到服务器的扭曲 SQL 吓坏了，首先，为了避免不必要的往返。

原文由 Doctor Eval 发布，翻译遵循 CC BY-SA 3.0 许可协议