Jpa与Hibernate-标准还是功能？

我们正在启动一个项目，我们的architet希望使用标准上的所有内容（Calendar而不是JodaTime-JPA2 vs Hibernate 4）。我使用的是JPA2，我意识到在“标准”和可移植性的借口下，很多功能都丢失了

所以我问这个问题：因为标准而失去一些功能值得吗？为什么

这是改变ORM来考虑可移植性的常见方法吗

他们有一个已经有7年历史的项目，仍然使用OJB作为他们的ORM。。。。。。你能给我一点启示吗

---

谢谢

选择JPA可能是个好主意——它将涵盖你需要的大部分内容。不过，我不会根据ORM切换的容易程度来做出决定——这很可能永远不会发生，即使发生了，也会有很多其他事情需要首先担心

---

如果您使用Hibernate作为JPA提供程序，您可以随时在需要的地方使用特定于Hibernate的功能。

根据我的经验，请使用Hibernate 4。您永远不会在应用程序中更改您的ORM框架。与非标准相比，标准的发布周期非常长。这使得获得新功能或错误修复变得困难。

---

此外，我想说Hibernate是一个准标准。Hibernate提供了比JPA更多的特性。我不会放弃它们。

标准解决方案的优点是每个人都在使用它们。这意味着：

雇佣熟悉技术的人会更容易，培训人员也会更容易

该库被放弃或不适合使用的可能性较小（例如，由于供应商锁定，提供商可以免收高昂的许可费），即使是这样，库的其他一些用户也可能已经开辟了迁移路径

如果需要，则更容易切换到标准的不同实现（谁能确定在软件维护的大概多年内不会出现这种需要？）

例如，如果Red Hat在困难时期停止免费提供新版本的hibernate，但现在却要求支付许可费，该怎么办？或者，如果Joda time的制造商停止开发怎么办

因此，在存在标准的地方使用标准是有意义的。牺牲一些开发的便利性来限制依赖性也是有意义的——牺牲多少是值得的，这是一个判断（当然有可能将库拖到类路径中而没有真正的好处。另一个极端是重新发明轮子，仅仅因为轮子还没有标准化。）

他们有一个已经有7年历史的项目，仍然使用OJB作为他们的ORM。。。。。。你能给我一点启示吗

---

可能是因为代码使用没有现代实现的API与OJB对话，这使得切换提供程序的成本非常（高得让人望而却步）。也许这正是您的架构师试图通过限制您使用标准API来防止的情况。

Hibernate具有其他功能，如Hibernate搜索和Envers。

快速一行程序：

JPA-用于将对象（在JPA中称为实体）持久化/访问/更新到数据库的Java规范（javaee的一部分）

Hibernate-JPA提供程序（即开源JPA规范实现之一）。另外请注意您可以使用Hibernate而不使用JPA

---

在我的博客上有更多详细信息

工作时间的日历？哦，所以他想使用低标准。他说，因为JodaTime不在java标准上，而且JPA与Calendar兼容……嗯，非常感谢您的解释。这对我帮助很大。架构师希望将DTO用于一切……而实体只用于持久化……您认为这是一种好方法吗？据我所知，使用DTO并不复杂……请不要只发布你认为相关的随机信息；我们正在寻找被问到的特定问题的具体答案。