Java - JDBC替代品[关闭]

Posted 2023-02-22

【中文标题】Java - JDBC替代品[关闭]

【英文标题】：Java - JDBC alternatives [closed]

【发布时间】：2011-01-24 17:13:09

【问题描述】：

这只是理论上的问题。

我在我的 Java 应用程序中使用 JDBC 来使用数据库（选择、插入、更新、删除或其他）。 我制作“手动”Java 类，其中将包含来自 DB 表的数据（属性 = db 列）。然后我进行查询（ResultSet）并用数据填充这些类。我不确定，如果这是正确的方法。

但我已经阅读了很多关于 JDO 和其他持久性解决方案的文章。

有人可以根据他们的经验推荐最常用的 JDBC 替代品吗？

我也想知道 JDO 相对于 JDBC 的优势（简单来说）。

我已经在谷歌上搜索了很多这样的东西，但“第一手”的意见总是最好的。

谢谢

【参考方案1】：

Java 中数据库持久化的故事已经很长，曲折：

JDBC 是每个人最终都使用 与数据库通信的低级 API。但是如果不使用更高级别的 API，您必须自己完成所有繁重的工作（编写 SQL 查询、将结果映射到对象等）。

EJB 1.0 CMP Entity Beans 是对更高级别 API 的首次尝试，并已被大型 Java EE 提供商（BEA、IBM）成功采用，但未被用户采用。实体 Bean 太复杂且开销太大（理解，性能不佳）。 失败！

EJB 2.0 CMP 尝试通过引入本地接口来降低实体 Bean 的一些复杂性，但大部分复杂性仍然存在。 EJB 2.0 也缺乏可移植性（因为对象-关系映射不是规范的一部分，因此部署描述符是专有的）。 失败！

然后是 JDO，它是对象持久性的数据存储不可知标准（可与 RDBMS、OODBMS、XML、Excel、LDAP 一起使用）。但是，虽然有几个开源实现，并且虽然 JDO 已被小型独立供应商采用（大多数 OODBMS 供应商希望 JDO 用户稍后从他们的 RDBMS 数据存储切换到 OODBMS ——但这显然从未发生过），但它未能被被大型 Java EE 玩家和用户采用（因为编织在开发时很痛苦并且吓坏了一些客户，奇怪的查询 API 实际上太抽象了）。因此，虽然标准本身并没有死，但我认为它是失败的。 失败！

事实上，尽管存在两个标准，但用户更喜欢使用专有 API，如 Toplink、旧播放器或 Hibernate，而不是 EJB CMP 和JDO 用于对象到关系数据库的持久性（标准之间的竞争、JDO 的定位不明确、CMP 的早期失败和糟糕的营销我相信在这方面有部分责任）和 Hibernate 实际上成为该领域事实上的标准（这是一个很好的开放源框架）。 成功！

然后 Sun 意识到他们必须简化事情（更一般地说是整个 Java EE），他们在 Java EE 5 中使用 JPA（Java Persistence API，它是EJB 3.0 是对象到关系数据库持久性的新标准。 JPA 统一了 EJB 2 CMP、JDO、Hibernate 和 TopLink API/产品，似乎在 EJB CMP 和 JDO 失败的地方取得了成功（易于使用和采用）。 成功！

总而言之，Java 的 数据库持久性 标准是 JPA 并且应该优先于其他专有 API（使用 Hibernate 的 JPA 实现很好，但使用 JPA API），除非ORM 不是您所需要的。它提供了比 JDBC 更高级别的 API，旨在为您节省大量手动工作（这很简单，但就是这样）。

【讨论】：

太棒了，这正是我想要的，非常感谢您的帮助！顺便说一句：你知道 NetBeans IDE 默认使用什么吗？ F.e.当我将 DB 表拖放到 JTable 时，NetBeans 会生成带有一些管理的类...使用实体管理器、查询结果等。

@Mike 谢谢。关于 NetBeans，最新版本默认支持 JPA（作为 Sun 的标准，这是有道理的）。事实上，EntityManager 是 JPA 的一部分。

+1 表示成功/失败。请注意，为了完整起见，我可能会将 JDBC RowSet 和 DataSet 与普通 JDBC 区分开来（这在某种程度上与 ADO.NET DataSet 相比）。从未使用过它们，也从未听说过有人使用它们。

您能否更新您的答案以包括对 MyBatis 的比较？

【参考方案2】：

如果您想自己编写 SQL，而不想要 ORM，您仍然可以从一些隐藏所有繁琐连接处理的框架中受益（try-catch-finally）。最终你会忘记关闭连接...

这样一个非常容易使用的框架是Spring JdbcTemplate。

【参考方案3】：

我可以推荐Hibernate。它被广泛使用（并且有充分的理由），并且 Java Persistence API 规范由 Hibernate 的主要设计者领导这一事实保证它会在可预见的未来存在:-) 如果可移植性和供应商中立性对您很重要，您可以通过 JPA 使用它，因此将来您可以轻松切换到另一个 JPA 实现。

由于缺乏对 JDO 的个人经验，我无法真正将两者进行比较。然而，乍一看，Hibernate（或一般的 ORM）的好处似乎与JDO page 中列出的几乎相同。对我来说最重要的几点是：

DB 中立性：Hibernate 在后台支持多种 SQL 方言，在 DB 之间切换就像在配置中更改一行一样简单 性能：默认情况下延迟获取，并且在后台进行了更多优化，您需要使用 JDBC 手动处理这些优化 您可以专注于您的域模型和 OO 设计，而不是较低级别的数据库问题（但如果您愿意，当然可以微调 DML 和 DDL）

一个潜在的缺点（通常是 ORM 工具）是它不适合批处理。如果您需要更新表中的 100 万行，默认情况下 ORM 永远不会像 JDBC 批量更新或存储过程那样执行。虽然 Hibernate 可以合并存储过程，并且它在一定程度上支持批处理（我对此还不熟悉，所以我不能说与 JDBC 相比它在这方面是否能胜任 - 但从我的到目前为止知道，可能是的）。因此，如果您的应用程序需要一些批处理但主要处理单个实体，那么 Hibernate 仍然可以工作。如果它主要做批处理，也许 JDBC 是更好的选择。

【讨论】：

+1 - 你打败了我。 Hibernate 是一个很好用的 ORM，它具有足够的灵活性，可以让您完成几乎所有您可以直接在 JDBC 中完成的任务。

是的，我听说过很多有关 Hibernate 的信息，您是否推荐在小型项目中使用它？像 50 个类，10-15 个数据库表？还是坚持手动 JDBC 数据管理？

@Mike 好问题。有人说这对于小型项目来说太过分了。我使用类似的 ORM 工具 Cayenne (cayenne.apache.org) 完成了一个较小的项目，我很满意。所以我肯定会试一试。 可能感觉你需要在启动时做很多“额外”的工作，但恕我直言，从长远来看它会有所回报。

【参考方案4】：

Hibernate 要求您有一个对象模型来映射您的架构。如果您仍然只考虑关系模式和 SQL，那么 Hibernate 可能不适合您。

您必须愿意接受 Hibernate 将为您生成的 SQL。如果您认为使用手工编写的 SQL 可以做得更好，那么 Hibernate 可能不适合您。

另一种选择是 iBatis。如果 JDBC 是原始 SQL，而 Hibernate 是 ORM，那么 iBatis 可以被认为是介于两者之间的东西。它使您可以更好地控制所执行的 SQL。

【讨论】：

+1 为 iBatis。经常被忽视，但非常适合使用 DBMS 的专有功能进行只读复杂查询。

太棒了 - 为什么不直接写 SQL 并避免臃肿？

【参考方案5】：

JDO 建立在 JDBC 技术之上。同样，Hibernate 也仍然需要 JDBC。 JDBC 是 Java 关于数据库连接的基本规范。

这意味着 JDBC 将为您提供更大的控制权，但它需要更多的管道代码。

JDO 提供了更高的抽象和更少的管道代码，因为很多复杂性都被隐藏了。

如果你问这个问题，我猜你对 JDBC 不熟悉。我认为需要对 JDBC 有基本的了解才能有效地使用 JDO、Hibernate 或任何其他更高的抽象工具。否则，您可能会遇到 ORM 工具表现出您可能无法理解的行为的情况。

Sun 在其网站上的 Java 教程提供了一份不错的介绍性材料，可引导您了解 JDBC。 http://java.sun.com/docs/books/tutorial/jdbc/.

【参考方案6】：

看看 MyBatis。经常被忽视，但非常适合使用 DBMS 的专有功能进行只读复杂查询。

http://www.mybatis.org

【参考方案7】：

以下是 java 持久性的表现。你刚刚学了java，现在你想持久化一些记录，你开始学习JDBC。您很高兴现在可以将数据保存到数据库中。然后你决定编写一个更大的应用程序。您意识到尝试、捕获、打开连接、关闭连接、将数据从结果集传输到您的 bean 已经变得乏味......所以您认为必须有更简单的方法。在java中总是有一个选择。所以你做了一些谷歌搜索，很快你就会发现 ORM，而且很可能是休眠。你是如此退出以至于你现在不必考虑连接。您的表是自动创建的。你可以移动得非常快。然后你决定进行一个非常大的项目，一开始你行动非常快，并且你已经完成了所有的 crud 操作。需求不断出现，然后有一天你会走投无路。您尝试保存，但它不会级联到对象子项。正如你读过的书中所解释的那样，某些事情已经完成了。您不知道该怎么做，因为您没有编写休眠库。您希望自己编写 SQL。现在是重新考虑的时候了……随着您的成熟，您会意识到与数据库交互的最佳方式是通过 SQL。您还意识到，有些工具可以让您快速入门，但它们无法让您持续很长时间。这是我的故事。我现在是一个非常快乐的 ibatis/用户。

【参考方案8】：

Ebean ORM 是另一种选择 http://ebean-orm.github.io/

Ebean 使用 JPA Annotations 进行映射，但它的架构是无会话的。这意味着您没有附加/分离的概念，也没有持久化/合并/刷新 - 您只需简单地保存（）您的 bean。

我希望 Ebean 比 Hibernate、JPA 或 JDO 更易于使用

因此，如果您正在寻找 JDO 或 JPA 的强大替代方法，您可以查看 Ebean。

【参考方案9】：

JPA/Hibernate 是 ORM 的流行选择。它可以为您提供所需的几乎所有 ORM 功能。对于那些有基本 ORM 需求的人来说，学习曲线可能很陡峭。

对于具有基本 ORM 要求的开发人员，有许多 JPA 替代方案可以为 ORM 提供更简单的复杂性。查询 sourceforge 例如： http://sourceforge.net/directory/language:java/?q=ORM

我偏爱我的解决方案，Sormula：sourceforge 或 bitbucket。 Sormula 旨在最大限度地降低复杂性，同时提供基本的 ORM。

【参考方案10】：

休眠，当然。它很受欢迎，甚至还有一个 .NET 版本。

此外，hibernate 可以很容易地与 Spring 框架集成。

而且，它几乎可以满足任何开发人员的需求。

【参考方案11】：

一个令人兴奋的新替代方案是GORM，它是来自 Grails 的 ORM 实现。现在可以单独使用。 在引擎盖下它使用 Hibernate，但在顶部为您提供了一个不错的层，带有很酷的动态查找器等。

【讨论】：

“在引擎盖下它使用 Hibernate” - 和 Spring。

【参考方案12】：

所有这些不同的抽象层最终都使用 JDBC。整个想法是自动化一些繁琐且容易出错的工作，就像编译器自动化编写程序时的许多繁琐工作一样（调整数据结构的大小 - 没问题，只需重新编译）。

但是，请注意，为了使这些功能发挥作用，您需要遵守一些假设。这些通常是合理的并且很容易使用，特别是如果您从 Java 端开始，而不是必须使用现有的数据库表。

JDO 是单一 Sun 标准中各种项目的融合，我建议您学习这个标准。对于实施，请选择您最喜欢的 IDE 在其各种向导中建议的那个。

【参考方案13】：

还有我个人更喜欢的扭矩 (http://db.apache.org/torque/)，因为它更简单，并且完全符合我的需要。

使用 Torque，我可以使用 mysql 定义数据库（我使用 Postgresql，但也支持 Mysql），然后 Torque 可以查询数据库，然后为数据库中的每个表生成 java 类。然后，您可以使用 Torque 查询数据库并取回正确类型的 Java 对象。

它支持 where 子句（使用 Criteria 对象或者您可以自己编写 sql）和连接。

它还支持外键，所以如果你有一个 User 表和一个 House 表，其中一个用户可以拥有 0 个或多个房子，用户对象上会有一个 getHouses() 方法，它会给你一个列表用户拥有的房屋对象。

要初步了解您可以编写的代码类型，请查看http://db.apache.org/torque/releases/torque-3.3/tutorial/step5.html，其中包含显示如何使用扭矩加载/保存/查询数据的示例。 （本示例中使用的所有类都是根据数据库定义自动生成的）。

【参考方案14】：

我推荐使用Hibernate，它连接数据库的方式非常棒，之前问题很少，但后来更稳定了。 它使用基于 ORM 的映射，它在一定程度上减少了编写查询的时间，并且允许以最少的工作量更改数据库。 如果您需要任何基于视频的教程，请告诉我，我可以上传到我的服务器并将链接发送给您。

【参考方案15】：

将 hibernate 用作独立的 JAR 文件，然后将其分发到不同的 Web 应用程序。这是目前最好的解决方案。你必须设计你的类、接口、枚举来做一个抽象的 DAO 模式。只要您有正确的实体和映射。您只需要使用对象（实体）而不是 HSQL。

【讨论】：

没有事实可以证明这是“最好的解决方案”

@Woot4Moo - 关于这个问题的一切都很糟糕。您应该专注于标记主观的“什么是最好的/向我推荐”的问题，以便结束。