我们正在启动一个项目，我们的架构师希望使用标准上的所有内容（日历而不是 JodaTime - JPA2 与 Hibernate 4）。我正在使用 JPA2，我意识到以“标准”和可移植性为借口丢失了很多功能。
所以我问这个问题：是否值得因为标准而失去一些功能？为什么？
改变 ORM 以考虑可移植性是常见的吗？
他们有一个项目已经 7 年了，仍然使用 OJB 作为他们的 ORM ......你能给我一个启示吗？
谢谢。
问问题
1150 次
5 回答
2
根据我的经验，使用 Hibernate 4。您永远不会在应用程序中更改您的 ORM 框架。与非标准相比，标准的发布周期非常长。这使得很难获得新功能或错误修复。此外，我会说 Hibernate 是一个准标准。Hibernate 提供了比 JPA 更多的功能。我不会放弃他们。
于 2012-06-21T02:51:29.303 回答
1
标准解决方案的优势在于每个人都在使用它们。这表示：
- 雇用熟悉技术的人会更容易，培训人会更容易
- 图书馆被遗弃或变得不适合使用的可能性较小（例如，由于供应商锁定，提供者可以逃避过高的许可费用）——即使是这样，其他一些用户图书馆可能开创了迁移路径
- 如果需要，切换到标准的不同实现会更容易（谁能确定在可能维护该软件的许多年内不会出现这种需要？）
例如，如果 Red Hat 陷入困境，停止免费提供新版本的 hibernate，但现在要求支付许可费怎么办？或者如果 Joda time 的制造商停止开发怎么办？
因此，在存在标准的地方使用标准是有意义的。牺牲一些开发的便利性来限制依赖关系也是有意义的——牺牲多少是值得的，这是一个判断（当然可以将库拖到类路径中而没有真正的好处。另一个极端是重新发明轮子，只是因为轮子还没有标准化。）
他们有一个项目已经 7 年了，仍然使用 OJB 作为他们的 ORM ......你能给我一个启示吗？
可能是因为代码使用没有现代实现的 API 与 OJB 通信，因此切换提供程序非常（禁止？）昂贵。也许这正是您的架构师试图通过限制您使用标准 api 来防止的情况。
于 2012-06-21T07:07:03.860 回答
0
选择 JPA 可能是个好主意——它将涵盖您需要的大部分内容。不过，我不会根据切换 ORM 的难易程度来做出决定——它可能永远不会发生，即使发生了，首先要担心的还有很多其他事情。
如果你使用 Hibernate 作为你的 JPA 提供者，你总是可以在你需要的地方回退到 Hibernate 特定的功能。
于 2012-06-21T02:08:24.377 回答
0
快速一班轮：
JPA - 用于将对象（在 JPA 中称为实体）持久化/访问/更新到数据库的 Java 规范（Java EE 的一部分）。
Hibernate - JPA 提供者（即开源 JPA 规范实现之一）。另请注意，您也可以在不使用 JPA 的情况下使用 Hibernate。
在我的博客上有更多详细信息，请点击此处。
于 2015-06-19T10:16:50.820 回答
-2
Hibernate 具有附加功能，例如 Hibernate-Search 和 Envers。
于 2012-10-03T03:25:00.447 回答