JDO 或 JPA 之间的“低风险”选择是什么？答案

【问题标题】：What's the "low risk" choice between JDO or JPA?JDO 或 JPA 之间的“低风险”选择是什么？
【发布时间】：2010-10-11 00:11:01
【问题描述】：

不要将其作为其他问题的重复项关闭，因为我问的不是同一件事。他们也大约一岁。也就是说，请参阅以下链接：

似乎 JPA 是大供应商支持的“流行”选择（如果可以的话，他们喜欢把你搞砸）。 JDO 似乎是更成熟、更优越的选择，应该得到更多 OSS 社区的支持。（但有吗？）

那么低风险容忍度组织应该做什么？从一个到另一个的难度是否大致相同？在这一点上，一个开始出现在另一个之上了吗？另外，仅因为我们当前使用它，Hibernate 是否将您限制为仅限 JPA？如果有，最流行的 JDO 实现是什么？

【问题讨论】：

【解决方案1】：

@Crusader - 是什么让你认为 SO 上的任何人都拥有比你更好的水晶球？

那么低风险容忍度的组织应该做什么？

选择它确定为低风险解决方案的替代方案。它如何确定风险最小的解决方案......尚不清楚......但我认为询问 SO 不是有效的风险评估程序。

另一点是，当 JPA 是“赢家”（反之亦然）时选择 JDO 可能不会在短期或长期内扼杀您的项目。做出错误选择的后果很可能仅限于更高的员工培训成本，并且被困在开发停滞不前且支持成本越来越高的基础 ORM 平台上。 [我会选择一个开源的 ORM 平台来保护自己免受后者的影响……无论如何。]

从一个到另一个的难度大致相同吗？

可能是的。尤其是当您考虑数据迁移问题时。

在这一点上，一个开始出现在另一个之上了吗？

如今，JPA 似乎占据主导地位。 JDO 的人会说他们的方法在技术上更优越，但这不是重点。

此外，仅因为我们目前使用它，Hibernate 是否将您限制为仅限 JPA？

JPA 加上特定于 Hibernate 的扩展。当然，Hibernate 不支持 JDO，而且它可能永远也不支持。

如果是的话，最流行的 JDO 实现是什么？

通过。

【讨论】：

【解决方案2】：

如果您使用像开源 exPOJO 这样的轻量级依赖注入和 ORM 包装框架，它可以让您完全绕过这个问题。您的主要代码库与底层持久性接口/技术完全无关（JDO、当前支持的 Hibernate 实现、正在开发的 JPA - 想伸出援手吗？）。

根据 Chris Richardson 的优秀著作“POJOs in Action”，所有持久性技术特定代码都封装在 Repository 和 Service 类中，并使用他在书中讨论的“公开域模型”模式进行公开 - 结果非常棒，而且我用过的最有效的方法。

使用 exPOJO，您 99% 的代码仍然可以在 JDO、JPA、Hibernate 之间轻松且即时地移植，另外您还可以获得极其轻量级和非常简单的依赖注入（无需注释或 XML）。

它带有自己的非常轻量级且易于使用的 servlet 过滤器，可以提供“开放的会话/持久性管理器/实体管理器”，而无需 XML 地狱。每个 HTTP 请求都会自动附加到一个 ModelExposer 对象，该对象提供对存储库和服务组件的便捷访问，从而允许对您的对象进行通用访问。

exPOJO 位于 http://www.expojo.com - 是的，好吧，我写的，所以我有点偏见 =]

【讨论】：

您知道 PicoContainer 吗？ expojo 有什么比 pico 做得更好？ Pico 是比 Spring-bloatware 框架更成熟的 DI 框架，非常轻量级，没有依赖关系，非常易于使用。您应该检查一下：picocontainer.org Picocontainer 最重要的是：没有 XML 地狱！
不，我还没有签出 picocontainer，但我会的。 expojo 也没有 XML 地狱 ;)