Google App Engine 上的 JDO 与 JPA for Java

Question

我想使用 Struts2 在 Google App Engine 上开发我的项目。对于数据库，我有两个选项 JPA 和 JDO。你们会建议我吗？两者对我来说都是新的，我需要学习它们。所以我会在你回复后专注于一个。

谢谢。

Answer 1

GAE/J google 小组有几篇关于这件事的帖子。我会在那里搜索并查看人们的意见。你会得到与上述观点截然不同的信息。还要关注 BigTable 不是 RDBMS 的事实。为工作使用正确的工具

Answer 2

JPA 是 Sun 的持久性标准，JDO 恕我直言正在消亡（实际上，它已经消亡但仍在发展）。换句话说，从长远来看，JPA 似乎是一项更好的投资。所以我想如果两者对我来说都是新手，我会选择 JPA。

Answer 3

刚刚看到 DataNucleus 自己对 JPA 和 JDO 进行了比较：- http://www.datanucleus.org/products/accessplatform_2_1/jdo_jpa_faq.html 大开眼界。

Answer 4

我是 JDO 的快乐用户。继续努力，伙计们。

Answer 5

声称 JDO 已死的人并非没有根据。这是我在 Pro EJB 3 Java Persistence API 一书中读到的内容：“不久之后，Sun 宣布 JDO 将简化为规范维护模式，Java Persistence API 将从 JDO 和其他持久性供应商那里汲取灵感，成为唯一受支持的标准向前发展。”。作者 Mike Keith 是 EJB3 的共同规范负责人。当然，他是 JPA 的大力支持者，但我怀疑他是否有足够的偏见撒谎。

确实，当本书出版时，大多数主要供应商都联合支持 JPA 而不是 JDO，尽管 JDO 确实具有比 JPA 更先进的技术特性。这并不奇怪，因为 EE 领域的大玩家，如 IBM/Oracle 也是大型 RDBMS 供应商。与非 RDMBS 相比，在他们的项目中使用 RDMBS 的客户更多。在 GAE 大力推动 JDO 之前，JDO 一直在消亡。这是有道理的，因为 GAE 数据存储不是关系数据库。一些 JPA 功能不适用于 bigtable，例如聚合查询、联接查询、拥有的多对多关系。顺便说一句，GAE 支持 JDO 2.3，而仅支持 JPA 1.0。如果 GAE 是您的目标云平台，我会推荐 JDO。

Answer 6

为了记录，它是 Google App Engine (GAE)，所以我们使用 Google 规则而不是 Oracle/Sun 规则。

在它下面，JPA 不适合 GAE，它不稳定，不能按预期工作。谷歌都不愿意支持它，但最低限度。

在其他方面，JDO 在 GAE 中相当稳定，并且（在某种程度上）被 Google 详细记录。

但是，Google 不推荐其中任何一个。

http://code.google.com/appengine/docs/java/datastore/overview.html

低级 API 将提供最佳性能，而 GAE 就是关于性能的。

http://gaejava.appspot.com/

例如添加10个实体

Python :68 毫秒

JDO :378 毫秒

Java 原生：30 毫秒

Answer 7

在 JDO 与 JPA 之间的比赛中，我只能同意 datanucleus 海报。

首先，也是最重要的，datanucleus 的发布者知道他们在做什么。毕竟，他们正在开发一个持久库，并且熟悉关系以外的数据模型，例如大桌子。我敢肯定，这里有一个 hibernate 开发人员，他会说：“我们在构建核心库时的所有假设都与关系模型紧密耦合，hibernate 没有针对 GAE 进行优化”。

其次，毫无疑问，JPA 的使用范围更广，成为官方 Java EE 堆栈的一部分会有所帮助，但这并不一定意味着它会更好。 事实上，如果您阅读过 JDO，它对应于比 JPA 更高级别的抽象。 JPA 与 RDBMS 数据模型紧密耦合。

从编程的角度来看，使用 JDO API 是一个更好的选择，因为您在概念上的妥协要少得多。理论上，您可以切换到您想要的任何数据模型，前提是您使用的提供程序支持底层数据库。 （实际上，您很少能达到如此高的透明度，因为您会发现自己在 GAE 的对象上设置了主键，并且您会将自己绑定到特定的数据库提供商，例如 google）。不过迁移起来还是比较容易的。

第三，您可以使用 Hibernate、Eclipse Link，甚至 Spring 与 GAE。谷歌似乎做了很大的努力来允许你使用你用来构建应用程序的框架。但是当人们像在 RDBMS 上运行一样构建 GAE 应用程序时，他们意识到它们很慢。 GAE 上的春天很慢。您可以在 Google IO 上搜索有关此主题的视频，看看是否属实。

此外，遵守标准是一件明智的事情，原则上我对此表示赞赏。另一方面，作为 Java EE 堆栈的一部分的 JPA 有时会让人们失去他们的选项概念。 如果您愿意，请意识到 Java Server Faces 也是 Java EE 堆栈的一部分。对于 Web GUI 开发来说，它是一个令人难以置信的整洁解决方案。但最后，为什么人们，如果我可以这么说的话，更聪明的人，会偏离这个标准而使用 GWT？

在所有这些中，我必须说明 JPA 有一件非常重要的事情。这就是 Guice 及其对 JPA 的便捷支持。似乎谷歌在这一点上不像往常那样聪明并且满足，目前不支持 JDO。我仍然认为他们负担得起，最终 Guice 也会吞并 JDO，……或者可能不会。

Answer 8

去 JDO。就算没有经验，上手也不难，一身新技能！

Answer 9

在撰写本文时，我认为使用 JDO 的糟糕之处在于，唯一的实现供应商是 Datanucleus，其缺点是缺乏竞争，这会导致许多问题，例如：

1. 关于 extensions 等某些方面的不是很详细的文档
2. 您通常会从作者那里得到讽刺性的回应，例如（您检查过日志吗？可能有它们的原因）以及诸如此类的烦人的回应
3. 您没有在很长一段时间内得到问题的答案，有时如果您在不到 7 天的时间内得到答案，您应该认为自己很幸运，即使在 StackOverflow 上也是如此

我一直希望有人自己开始实施JDO 规范，可能到那时他们会提供更多的东西，并希望更多地免费关注社区，而不是总是为成为付费支持，并不是说Datanucleus作者只关心商业支持，但我只是说。

我个人认为Datanucleus 作者对Datanucleus 本身及其社区没有任何义务。他们可以随时放弃整个项目，没有人可以评判他们，这是他们的努力和他们自己的财产。但是你应该知道你在做什么。你看，当我们中的一个开发人员寻找要使用的框架时，你不能惩罚或命令框架的作者，但另一方面，你需要完成你的工作！如果您有时间编写该框架，您为什么要首先寻找一个？！

另一方面，JDO 本身也有一些复杂性，比如对象生命周期和不太直观和常见的东西（我认为）。

编辑：现在我也知道 JPA 强制执行对象生命周期机制，因此如果您希望使用标准 ORM API（即 JPA 或 @987654332 @)

我最喜欢JDO 的地方在于能够轻松使用任何数据库管理系统。

Answer 10

GAE/J 计划在年底前添加 MYSQL。

Answer 11

JPA 是一种可行的方法，因为它似乎被推为标准化 API，并且最近在 EJB3.0 中获得了动力。JDO 似乎失去了动力。

Answer 12

没有！

使用 Objectify，因为它更便宜（使用更少的资源）并且速度更快。 仅供参考：http://paulonjava.blogspot.mx/2010/12/tuning-google-appengine.html

Objectify 是一个 Java 数据访问 API，专为 谷歌应用引擎数据存储。它占据了“中间地带”；更容易 使用并且比 JDO 或 JPA 更透明，但明显更多 比低级 API 更方便。 Objectify 旨在使 新手立即富有成效，同时也暴露了 GAE 数据存储。

Objectify 让您可以持久化、检索、删除和查询您自己的类型化对象。

@Entity
class Car {
    @Id String vin; // Can be Long, long, or String
    String color;
}

ofy().save().entity(new Car("123123", "red")).now();
Car c = ofy().load().type(Car.class).id("123123").now();
ofy().delete().entity(c);