Java 对现有数据库使用Hibernate

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

但我们遇到了一个问题。对已经存在的数据库使用Hibernate并围绕模式对对象进行建模，这不是一个好主意吗

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

---

有经验吗？

我想说，在不知道您的需求的情况下选择Hibernate、iBatis或其他任何东西是不负责任的

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

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

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

明白了吗？像那些冬眠支持者那样的下意识反应不是个好主意

可能iBatis或SpringJDBC模板是比Hibernate更好的选择。你应该更多地了解这个决定，并为你的申请做出决定，而不是盲目地听取暴徒的意见

你也不必对此全神贯注。可以用一种技术实现解决方案的一部分，用另一种技术实现其余部分

---

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

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

---

如果我想跳过ORM部分，我发现我自己对它非常满意，我更喜欢它，正如其他人指出的那样，如果数据库离对象模型不远，ORM只是一个不错的选择

如果是这种情况，那么一个选项是通过JPA休眠，原因有两个：

• Netbeans有一个从现有数据库生成JPA实体的工具。这些实体不依赖于Netbeans，因此您可以在初始反向工程之后使用不同的IDE

• SpringDataJPA可以避免编写琐碎的查询，而专注于困难的查询

---

我建议查看（NoORM对象映射器）。它是为SQL first开发而设计的，非常适合改装现有模式。

如果其他应用程序也更新数据库，则Hibernate可能不是一个好选择-在这种情况下，您至少需要确保Hibernate的二级缓存未启用。此外，即使您有一个“实体对象模型”，如果它与通常的hibernate模式非常不同，您可能会发现数据访问效率非常低。我还要补充一点，“实体对象模型”非常主观。我认为hibernate/jpa迫使您做一些非常反OOD的事情。（倒数第二段）我非常佩服马丁·福勒，但我要指出，这篇文章已经有十年的历史了。埃里克·埃文斯的DDD并没有横扫世界。“过程编程”这个短语听起来几乎是肮脏的。很多面向对象的模式都是为了解决函数式/过程式编程所没有的缺点。我不同意将持久性放在模型对象中是一种反模式。这仍然是一个很好的评论。@duffymo procedural是，functional不是。很多OO模式在函数式语言中都是不必要的。JDBI单独来说可能是一个很好的解决方案，但因为OP无论如何都会使用Spring，所以在这种情况下，Spring JDBC模板更可能是一个选择。它们非常相似，但我喜欢在JDBI中实现fluent API的方式。这也是一个有趣的实验，我发现hibernate在使用复合外键时有很大的困难。