不要将此作为其他问题的副本关闭，因为我不是在问同样的事情。他们也大约一岁。也就是说，请看这些链接：
http://db.apache.org/jdo/jdo_v_jpa.html
http://www.datanucleus.org/products/accessplatform/jdo_jpa_faq.html
http://www.datanucleus.org/products/accessplatform/persistence_api.html
似乎JPA是大型供应商支持的“受欢迎”选择（如果可能的话，他们喜欢把你搞砸）。 似乎JDO是更成熟，看似更优越的选择，应该享受更多的OSS社区支持。 （但是吗？）
那么低风险容忍组织应该做什么？从一个到另一个的难度是否相同？此时有人开始出现在另一个之上吗？另外，仅仅因为我们目前使用它，Hibernate是否仅限于JPA？如果是这样，最流行的JDO实现是什么？
答案 0 :(得分：1)
@Crusader - 是什么让你认为SO上的任何人都有比你更好的水晶球？
那么低风险的宽容组织应该做些什么呢？
选择它确定为低风险解决方案的替代方案。它如何确定哪种解决方案风险最小......不清楚......但我不认为要求SO是一种有效的风险评估程序。
另一点是，当JPA是“赢家”（或反之亦然）时选择JDO可能不会在短期或长期内扼杀您的项目。做出错误选择的后果很可能仅限于更高的员工培训成本，并且陷入基础ORM平台，开发停滞不前，支持越来越昂贵。 [我会通过选择一个开源的ORM平台来保护自己免受后者攻击......无论如何。]
从一个到另一个的难度是否相同？
可能是的。特别是在考虑数据迁移问题时。
此时是否有人开始出现在另一个之上？
JPA似乎在这些日子里占主导地位。 JDO人员会说他们的方式在技术上是优越的，但这不是重点。
另外，仅仅因为我们目前使用它，Hibernate是否仅限于JPA？
JPA加上特定于Hibernate的扩展。当然Hibernate也不支持JDO，它可能永远不会。
如果是这样，最流行的JDO实现是什么？
通。
答案 1 :(得分：0)
如果您使用轻量级依赖注入和ORM包装框架（如开源exPOJO），它允许您完全绕过该问题。您的主要代码库仍然完全不了解底层持久性接口/技术（当前支持的JDO，Hibernate实现，JPA正在路上 - 比如伸出援助之手？）。
所有持久性技术特定代码都根据Chris Richardson出色的书“POJO in Action”封装在Repository和Service类中，并使用他在书中讨论的“暴露域模型”模式进行了公开 - 结果证明它非常棒，我用过的最有效的方法。
使用exPOJO 99％的代码仍然可以在JDO，JPA，Hibernate之间立即移植，并且您可以获得非常轻量级和非常简单的依赖注入（无需注释或XML）作为额外的奖励。
它附带了它自己的非常轻量级且易于使用的servlet过滤器，可以在没有XML地狱的情况下提供“开放会话/持久性管理器/实体管理器”。每个HTTP请求都自动附加到ModelExposer对象，该对象提供对存储库和服务组件的便捷访问，允许对对象进行通用访问。
exPOJO在http://www.expojo.com - 是的，我写的所以我有点偏见=]