对现有数据库使用 Hibernate答案

【问题标题】：Using Hibernate for Existing Database对现有数据库使用 Hibernate
【发布时间】：2013-01-09 01:48:45
【问题描述】：

我们有一个已经运行了很长时间的应用程序。现在我们正在将它迁移到 Spring 并可能使用 Hibernate 或任何其他 ORM。

但是我们遇到了一个问题。对已经存在的数据库使用 Hibernate 并围绕 Schema 对对象进行建模是不推荐/坏主意吗？

大多数人主张不要使用 Hibernate，而不是使用其他一些 ORM，例如 iBatis。但在我们公司，所有人都是 Hibernate 的支持者。

有什么经验吗？

【问题讨论】：

【解决方案1】：

如果您可以在对象下为数据库建模，那么 Hibernate 会很好地工作。
反之亦然，您很可能将数据库模型作为您的域模型。您需要评估这两个模型的距离，否则您将映射数据库 => ORM 对象 => 您的域模型。我会避免这种情况。

如果我想跳过 ORM 部分，我发现自己对 JDBI 非常满意，我更喜欢 Spring JDBC Template

【讨论】：

单独使用 JDBI 可能是一个不错的解决方案，但由于 OP 无论如何都将使用 Spring，因此在这种情况下 Spring JDBC Template 是一个更可能的选择。
它们非常相似，但我喜欢在 JDBI 中实现流畅的 API。这也是一个有趣的实验iciql.com

【解决方案2】：

我会说，在不了解您的要求的情况下选择 Hibernate、iBatis 或其他任何东西是不负责任的。

如果您没有实体对象模型，我会说 Hibernate 是一个糟糕的选择。

如果您使用存储过程作为数据库的接口，我会说 Hibernate 是一个糟糕的选择。

如果您不喜欢 Hibernate 为您生成的动态 SQL，我会说 Hibernate 是一个糟糕的选择。

明白了吗？像那些 Hibernate 支持者那样的下意识反应并不是一个好主意。

可能 iBatis 或 Spring JDBC 模板是比 Hibernate 更好的选择。您应该更加了解该决定并为您的申请做出决定，而不是盲目地听从暴民的意见。

您也不必全神贯注或一无所获。可以使用一种技术实现部分解决方案，而用另一种技术实现其余部分。

我建议让你的持久层基于接口，这样你就可以在不影响客户端的情况下交换实现。

【讨论】：

如果其他应用程序也更新数据库，Hibernate 也可能不是一个好的选择 - 在这种情况下，您至少需要确保未启用 Hibernate 的二级缓存。此外，即使您有一个“实体对象模型”，如果它与通常的休眠模式模式有很大不同，您可能会发现数据访问效率非常低。
我还要补充一点，“实体模型”是非常主观的。我认为 hibernate/jpa 迫使你做一些非常反 OOD 的事情。 I'll let Martin Fowler defend my controversial statement :)（倒数第二段）
我很佩服Martin Fowler，但是我要指出这篇文章已经快十年了。 Eric Evans DDD 并没有超越世界。 “过程式编程”这个短语听起来几乎很脏。许多面向对象模式的出现是为了解决函数式/过程式编程所没有的缺点。我不同意将持久性放在模型对象中是一种反模式。这仍然是一个很好的评论。
@duffymo 程序是的，功能没有。在函数式语言中，很多 OO 模式是不必要的。

【解决方案3】：

我建议查看SansORM（NoORM 对象映射器）。它专为 SQL 优先开发而设计，非常适合改造现有架构。

【讨论】：

【解决方案4】：

正如其他人指出的那样，只有当您的数据库离对象模型不远时，ORM 才是一个不错的选择。

如果是这种情况，那么一个选项将是通过 JPA 休眠两个响应：

【讨论】：