用于数据库应用程序的 Java JDBC 与 JPA [关闭]答案

【问题标题】：Java JDBC vs JPA for database application [closed]用于数据库应用程序的 Java JDBC 与 JPA [关闭]
【发布时间】：2011-10-10 16:49:38
【问题描述】：

我想说的是，我有点像新手，在努力养成良好习惯时寻求建议。

我现在正在开发的应用程序是一个高度集成的数据库应用程序。当我为每个实体开发、探索和实现需求时，我发现我的类只是在扩展代码，以便在每个实体上以不同的方式运行查询。

虽然现在这可能不是一件坏事，但在维护方面，我预见我的应用程序在调试和更新方面是一场噩梦。

是否有任何 JDBC 专家对设计模式有任何建议，以帮助减少处理所有这些查询的样板类型代码？还是我应该完全偏离并使用JPA？

我过去曾尝试实现 JPA，但在处理复杂的实体关系时遇到了麻烦。我应该读一本 JPA 的书然后从那里开始吗？

【问题讨论】：

标签： java design-patterns jpa jdbc

【解决方案1】：

JPA 可以是一个很好的长期解决方案。但如果您更喜欢更接近纯 SQL，则可以考虑其他选项，例如 Spring Framework's JDBC support。

请注意，您无需使用其他 Spring 框架组件链接 DI、MVC 等即可使用 Spring JDBC。无需其他部件弹簧框架，安静易于使用。使用 spring jdbc 时，您不需要在代码中执行以下任务：

打开连接。
准备并执行语句。
设置循环以遍历结果（如果有）。
处理任何异常。
处理事务。
关闭连接、语句和结果集。

你需要做的是：

定义连接参数。（一次）
指定 SQL 语句。（针对每个查询）
声明参数并提供参数值（使用准备好的语句时）
为每次迭代完成工作。（spring做resultset遍历，只需要提供作用于单行的逻辑）

spring-jdbc 的另一个好处是它用未经检查的异常替换了 JDBC 已检查的异常。

【讨论】：

所以我很困惑，为什么UNchecked exceptions比checked exceptions更好？
@Dennis：请参阅the exceptions debate，详细了解受检异常与未受检异常的优缺点。

【解决方案2】：

无论您使用什么解决方案，无论是直接的 JDBC 还是 JPA，请务必将您的代码分解成可以在需要更改技术时轻松替换的部分。

JDBC 的缺点是您最终可能会使用特定于实现的代码（Oracle、MS、MySQL 等）。如果您决定在未来进行更改，那么迁移起来可能会非常痛苦。

我最终学习了 Hibernate，而这本书 Harnessing Hibernate 让我在进行这种开发方面有了相当多的方法（也让 Spring 和 Maven 一起参与其中，以慢慢建立在彼此之上的方式.)

无论采用何种方法，您最终应该得到的是：

DAO 对象 -- 这些数据访问对象将执行您的 CRUD 操作（创建、更新和删除），并且应该与数据库无关。
模型对象——它们应该代表您的数据，并且可能看起来很像数据库表中单行的 Java 表示。 DAO 类将返回这些或这些列表。

利用 Hibernate 在后面的章节中描述了一种模式（在它向您抛出 Spring 之后），您将在其中使用基本上两层的 DAO 类。最高级别的 DAO 类将实例化（或允许注入）特定于实现的 DAO 类。

所以，让我们假设您有一个 EMPLOYEE 数据库表。因此，您创建了一个名为 Employee 的模型对象，该对象包含 EMPLOYEE 表中的一行所包含的所有数据。现在您创建一个名为 EmployeeDAO 的 DAO 类，它实现了以下内容：

EmployeeDAO.createEmployee(Employee emp)
EmployeeDAO.updateEmployee(Employee emp)
EmployeeDAO.deleteEmployee(Employee emp)

您最初的想法是将 JDBC 调用放在那里。但不要这样做。相反，您现在为 Employee 编写另一个 DAO，这个 DAO 将实现您的所有 JDBC 调用。（假设你使用 JDBC）：

EmployeeJdbcDAO.create(Employee emp)
EmployeeJdbcDAO.update(Employee emp)
EmployeeJdbcDAO.delete(Employee emp)

现在 EmployeeDAO 中的方法？他们只是简单地实例化 EmployeeJdbcDAO，并调用适当的方法。当需要使用 Hibernate 切换到 Oracle 时，您创建一个名为 EmployeeOrHibDAO 之类的新 DAO 类，在那里编写 Hibernate 和 Oracle 特定代码，然后在 EmployeeDAO 中调用 EmployeeJdbcDAO 而不是实例化 EmployeeOrHibDAO。（使用 Spring，您甚至无需更改代码。您只需更改 Spring DI 配置。）

【讨论】：

我认为您应该阅读我在否决我的提案之前所做的同一本书，因为您绝对可以编写一个可以用 Hibernate（或其他 ORM）DAO 替换的 JDBC DAO。如果 JDBC 是采用的路线，那么这个提议将限制 JDBC 代码的内聚性，从而更容易转向另一个解决方案。这是模式的关键点。您所要做的就是编写一个新的 DAO 并使用 Spring 将其注入应用程序。
它被称为 Harnessing Hibernate。它在原始帖子中链接到。
感谢您提供指向模式描述的链接。因此，这里是对 DAO 组件的描述：“DataAccessObject 是该模式的主要对象。DataAccessObject 抽象了 BusinessObject 的底层数据访问实现，以实现对数据源的透明访问。BusinessObject 还委托数据加载和将操作存储到 DataAccessObject。”本文档中的什么地方说它不能抽象 JDBC 实现？事实上，它甚至可以说它甚至不必是 RDMS 实现。
我们不是在谈论编写 ORM。我们正在讨论编写一个 DAO 来抽象基本的 CRUD 操作。创建、读取、更新和删除。所有这些方法（在您指出的 DAO 模式中调用）都可以使用诸如 Hibernate 或 JDBC 之类的 ORM 轻松实现。我怀疑大多数应用程序（当然是我研究过的应用程序）可以在没有您列出的方法的情况下通过。我进一步推测，最初的问题与一个开始的应用程序有关，而我不知道的事情并不像你所说的那样先进。
我喜欢 Java 社区的一件事。 . .他们提倡技术解决方案而不是市场言论。像 Unices（复数 Unix）一样，它使用“一切都是文件”资源访问和内核以及围绕内核的分层服务和应用程序。 (CR) 所以在我看来，最近对 JPA 数据库访问的推广是一种标准化的、封装抽象的最佳实践，也是新发展的方向。它技术先进，维护成本低。

【解决方案3】：

不是一个真正的答案，但我确实认为在组合中加入更多选项很重要，这可能会帮助您找到一个好的中间立场。我建议这样做是因为在具有大量复杂性和查询的现有数据库上实现 JPA 对于没有相当多的战斗伤痕的人来说可能有点麻烦。考虑以下但做研究并构建一些跟踪子弹应用程序；

Spring JDBCTemplate and DAO Pattern 喜欢 JPA\Hibernate 没有意义的解决方案。
MyBatis 同样，另一个不错的中间地带，对 SQL 有更多的控制

【讨论】：

这些都是很好的答案！不过，我对您的第 1 点有点好奇：您是否有一个快速、概括的示例说明 JPA/Hibernate 没有意义的地方？
不需要 JPA 包袱或遗留数据库的简单应用程序，我将花更多时间融入 JPA，而不仅仅是构建一些 DAO。

【解决方案4】：

如果您希望养成良好的习惯，我会阅读 Steve McConnell 的 Code Complete 2。

【讨论】：

Code Complete 2 有很多很棒的东西，但我认为它并不真正适用于问题的具体细节。

【解决方案5】：

不要放弃 active record pattern 作为选项。这不一定是 EJB 实体方法。该模式值得一提，恕我直言

【讨论】：