数据库层非 ORM (Java)答案

【问题标题】：Database Layer non-ORM (Java)数据库层非 ORM (Java)
【发布时间】：2012-04-23 02:06:50
【问题描述】：

我想编写 Java 代码来处理数据库，无论使用哪个数据库。我的问题是它不会与对象相关。有一些插入和查询是但大多数不是。

现在我们使用的是 Postgresql 和纯 JDBC，但我们可能必须让它与 Oracle 一起使用。

Hibernate（我从未使用过）能否解决我的问题，还是我应该去做其他事情？

【问题讨论】：

【解决方案1】：

我正是为此创建了jOOQ。 jOOQ 将 SQL 本身建模为 Java 中的 domain-specific language。它包含使用标准和特定于供应商的功能，例如内置函数、窗口函数、存储过程、分层查询等。只要有可能，就会为其他数据库模拟来自一个数据库的特定于供应商的功能。这样一来，jOOQ 生成的大部分 SQL 都与它支持的 13 个数据库中的任何一个兼容。

【讨论】：

现在，这就是我想要的。谢谢！我会在接下来的几天里研究它。

【解决方案2】：

我喜欢@unludo 的 JPA 答案，但我想我会添加一些额外的细节。

我建议您更改代码以使用您定义的持久性接口。

  public interface DataPersister {
     public void saveFoo(Foo foo);
     public void findFooById(int id);
     ...
  }

您的接口的第一个实现将使用 JDBC/Postgresql。如果您想在幕后使用 JPA，那很好。或者，如果您想切换到一些非 SQL 数据库甚至是平面文件，那么也可以。

一旦您在自己的代码中区分了数据的使用和持久化实现，那么切换到不同的持久化器就容易多了。您可以使用 H2 等廉价数据库进行测试，并在生产中切换到 Postgresql，同时在不久的将来迁移到新数据库。

希望这会有所帮助。

【讨论】：

这正是我的做法。我将一个 CRM 系统从 JDBC 移植到了 Hibernate，我发现我们仍然需要一些本地查询才能将它投入生产，并且使用语言作为接口是实现它的方法。
由于我没有时间（我没有）我没有用接口实现这个。是的，我噘嘴 DAO 层，但没有接口。我会尽快完成的。

【解决方案3】：

Hibernate 的问题是您需要像对象模型一样对关系数据库进行建模。有时这使得使用现有数据库变得困难。所以这取决于你的关系数据库。

其他框架（不是 JPA）是 Ibatis。试试看这个框架。

【讨论】：

【解决方案4】：

Java 的标准是 JPA，它非常强大。 Hibernate 是 JPA 提供者的行业标准。

JPA 可帮助您编写干净的持久层。您可以编写确保不会中断的查询，因为它们在编译时进行了验证。我喜欢为此使用spring，它很容易进行单元测试。但我相信 CDI 现在提供的功能相同。

编写测试类也很容易。正如一位同事曾经教我的那样，模型是你拥有的最重要的东西。您不希望它损坏或遇到问题。

使用 JPA，您还可以为要使用的任何数据库从实体生成模式。从经验来看，也很不错。

JPA 可帮助您将良好实践付诸实践。这很有价值。

关于@hvgotcodes 的回答，是的，您必须小心成本，但您也可以混合使用 jdbc 和 jpa。这就是道的用途。

【讨论】：

【解决方案5】：

编写自己的 sql 的问题是您需要为您的 RDBMS 手动优化它。一些 RDBMS 支持不同的 sql 结构。

因此，您需要在这与切换到基于 ORM 的解决方案的开销之间取得平衡。或者，确保您的 sql 是 100% 标准的，这样您就不会使用任何适用于一种 RDBMS 解决方案而不适用于另一种解决方案的构造。

在您的特定情况下，修复您的 sql 可能比重新设计整个持久层以使用 ORM 更容易。有时最好的工具就是你知道的那个。如果您当前的应用程序没有简洁的模型层，那么切换到 ORM 将需要大量工作。您当然可以使用 hibernate 并只使用 strait sql 查询，但是如果您不打算对数据进行建模，那还有什么意义呢。

希望您所有的持久性问题都集中在一个 DAO 层中，其中包含大量集成测试，因此您可以在切换 RDBMS 时快速识别出哪些问题。如果您没有专注于持久性的集成测试，那么现在是时候开始编写它们了。

【讨论】：