休眠与 JDBI [关闭]答案

【问题标题】：Hibernate vs JDBI [closed]休眠与 JDBI [关闭]
【发布时间】：2014-12-14 05:52:51
【问题描述】：

我正在使用 Dropwizard 框架（版本 0.7.0）构建一个 Web 服务。它涉及对数据库执行一些只读查询，操作结果集，然后返回该数据集。我使用 MySQL 作为数据库引擎。由于我是这个框架的新手，我想知道我应该选择哪个选项：Hibernate 或 JDBI。

【问题讨论】：

标签： java sql hibernate dropwizard jdbi

【解决方案1】：

这两个我都用过。我在 Grails 以及传统的 Spring 应用程序中使用了 Hibernate 和 GORM，并且在 Dropwizard 中使用了 JDBI。

我非常喜欢 JDBI 的简单性，以下是我更喜欢它而不是 Hibernate 的几个原因。

我确切地知道要执行什么 SQL 来获取我请求的数据。使用 Hibernate，您有时可能不得不对 HQL 进行大量处理，并将您的对象配置为您想要返回的内容。您最终求助于 SQL，但很难将结果正确映射回域对象，或者您放弃并允许 hibernate 一个一个地获取它们。
我无需担心延迟/急切获取以及这将如何影响我在大型数据集上的查询时间。
映射并不复杂，因为您可以自行管理它们，而且您不必依赖获得正确的注释和优化组合。

特别是对于您的情况，听起来您想要一些轻量级的东西，因为您没有很多用例，在我看来，这肯定是 JDBI 而不是 Hibernate。

【讨论】：

【解决方案2】：

真的，这两种解决方案都只是“锁定”。

如果您想使用持久模型类型接口，请针对 JPA（如果您确定它只会返回到关系数据库）或 JDO（如果您可能想要返回到关系和其他类型）编写代码数据库，如无 SQL 运动）。这是因为使用这些解决方案中的任何一个，当出现问题时，您都可以切换持久性提供程序，而无需重写大部分代码。

如果您想使用过程持久性模型（直接处理 SQL 查询等），那么使用 JDBi 甚至 JDBC。 JDBi 在 JDBC 之上提供了一个非常好的抽象；但是，在某些情况下，您需要较低级别的访问权限（出于性能原因，您正在协同调整查询和数据库）。同样，JDBC 是一种标准，因此您可以轻松地将一个数据库换成另一个数据库；但是，SQL 本身不会那么容易换出。

要修正 SQL 交换问题，我建议使用属性文件集来保存查询，然后使用资源加载器类型机制将正确数据库的 SQL 绑定到代码。它不是 100% 万无一失的。但它确实让你走得更远。

现在，如果你问我会用什么，我强烈推荐 JDO。

【讨论】：

“在不重写大部分代码的情况下切换持久性提供程序”有点……太乐观了。对于一个不平凡的项目，更改 JPA 提供者将是一个挑战。我过去参与过这样的项目（Hibernate -> EclipseLink），结果比预期的要困难得多。（这是一个纯粹的基于 JPA 的应用程序！）。如果您的应用程序使用了一些没有 JPA 替代方案的扩展（如 hibernate-envers）......
@Gmugra 如果您对仅使用 ANSI SQL（几乎没有人限制自己）保持非常严格的控制，您可以很容易地切换。问题是人们最终将服务器特定的扩展加入到不可移植的 SQL 或 DML 命令中。 JDO 的好处是 JDO 堆栈将编写您的 SQL 以匹配服务器，如果您这样做的话。
用简单的应用程序，只需要简单的SQL，你就可以了。（但为什么要为琐碎的应用程序使用巨大的 ORM？）但是任何，即使是相对简单的左右步骤都会导致可能的问题。例如我们在相对简单的 JPQL 查询中遇到了很多问题，这些查询可以在 Hibernate 中正常工作，但需要对 EclipseLink 进行修改（通常是一个愚蠢的修改）。此外，JPA 规范并不总是 100% 明确。在某些情况下，提供者可能会采用不同的方式，根据规范，这些方式都可以，但彼此不兼容。
@Gmugra 正如我之前所说，您总是可以选择 JDO。无需 SQL，无需傻傻地修改 SQL。

【解决方案3】：

如果您在数据库方面的工作很少，那么请使用 JDBI，否则请使用 Hibernate，因为它非常强大并且为您的持久性逻辑提供了许多附加功能。

【讨论】：