Google App Engine上的Java版JDO与JPA

我想使用Struts2在Google App Engine上开发项目。对于数据库，我有两个选项JPA和JDO。你们能建议我吗？两者对我来说都是新手，我需要学习它们。因此，在您回复之后，我将重点介绍一个。

谢谢。

JPA是Sun的持久性标准，JDO快死了（实际上，它已经死了，但仍在发展）。换句话说，从长远来看，JPA似乎是更好的投资。因此，如果两者都不是我的话，我想我会选择JPA。

GAE / J google小组有几篇有关此问题的文章。我会在那里搜索并查看人们的意见。您将获得与上述意见截然不同的信息。还应关注BigTable不是RDBMS的事实。使用正确的工具完成工作

刚看到通过自己DataNucleus将JPA和JDO之间的比较： - http://www.datanucleus.org/products/accessplatform_2_1/jdo_jpa_faq.html 大开眼界。

我是JDO的快乐用户。保持良好的工作状态。

人们声称JDO已死并非没有道理。这是我在Pro EJB 3 Java Persistence API一书中读到的内容：“此后不久，Sun宣布将JDO简化为规范维护模式，并且Java Persistence API将借鉴JDO和其他持久性供应商，并成为受支持的单一厂商。标准。”。作者Mike Keith是EJB3的共同规范负责人。当然，他是JPA的大力支持者，但我怀疑他是否有足够的偏见以至于撒谎。

的确，当本书出版时，尽管JDO确实比JPA具有更先进的技术功能，但大多数主要供应商都团结在JPA而非JDO的后面。毫不奇怪，因为EE世界中的大型参与者（例如IBM / Oracle）也是大型RDBMS供应商。在他们的项目中，使用RDMBS的客户多于使用非RDMBS的客户。JDO在GAE大力推动之前一直垂死。这是有道理的，因为GAE数据存储区不是关系数据库。JPA的某些功能不适用于bigtable，例如聚合查询，Join查询，拥有的多对多关系。顺便说一句，GAE支持JDO 2.3，而仅支持JPA 1.0。如果GAE是您的目标云平台，我将推荐JDO。

作为记录，它是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：68ms

JDO：378ms

Java Native：30毫秒

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

首先，也是最重要的是，数据核的发布者知道他们在做什么。他们毕竟正在开发一个持久性库，并且熟悉关系数据库以外的数据模型，例如Big Table。我确信ID的开发人员在这里，他会说：“构建核心库时，我们所有的假设都与关系模型紧密相关，而Hibernate并未针对GAE进行优化”。

其次，毫无疑问，JPA的使用更加广泛，它是官方Java EE堆栈的一部分，但有所帮助，但这并不一定意味着它会更好。实际上，如果您了解JDO，则它对应的抽象级别比JPA高。JPA与RDBMS数据模型紧密耦合。

从编程的角度来看，使用JDO API是更好的选择，因为从概念上讲，您的危害要小得多。从理论上讲，只要您使用的提供者支持基础数据库，就可以切换到所需的任何数据模型。（实际上，您很少达到如此高的透明度，因为您会发现自己在GAE的对象上设置了主键，并且将自己与特定的数据库提供者联系在一起，例如google）。迁移起来仍然会更容易。

第三，您可以将Hibernate，Eclipse Link甚至spring与GAE一起使用。Google似乎已经做出了很大的努力，以允许您使用用来构建应用程序的框架。但是人们在构建自己的GAE应用程序时就好像在RDBMS上运行一样，意识到它们运行缓慢。GAE的运行缓慢。您可以在该主题上用Google IO谷歌搜索以确认它是真的。

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

在所有这些方面，我必须确保JPA有一件非常重要的事情。这就是Guice及其对JPA的方便支持。似乎google在这一点上还不如往常聪明，并且在目前不支持JDO方面很满足。我仍然认为他们可以负担得起，最终Guice也将吞并JDO，……也许不是。

去JDO。即使您没有经验，也不难掌握，并且您将掌握新技能！

我认为JDO在撰写本文时使用的是可怕的是唯一的实现供应商Datanucleus，而缺点是缺乏竞争，这导致了许多问题，例如：

1. 关于某些方面的文档不是很详细 extensions
2. 通常，您会收到作者的讽刺回答，例如（您是否检查过日志？可能是有日志的原因）和类似的令人讨厌的回答
3. 您不会在有用的时间内得到问题的答案，有时，如果您在不到7天的时间内得到了答案，即使在这里，您也应该认为自己很幸运 StackOverflow

我一直希望有人能够JDO自己开始实施该规范，也许那样他们就可以向社区提供更多，希望更多的自由关注，而不必总是为获得支持而付费，而不是说Datanucleus作者只在乎商业支持。 ，但我只是说。

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

另一方面，JDO它本身具有一些复杂性，例如对象的生命周期和东西，这些不是很直观和常见（我认为）。

编辑：现在，我知道还JPA强制执行对象生命周期机制，因此，如果您希望使用标准的ORM API（即JPA或JDO），那么处理持久化实体生命周期状态似乎是不可避免的

我最喜欢的JDO是无需任何努力即可使用ANY数据库管理系统的功能。

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

JPA似乎已经成为一种标准化的API，并且最近在EJB3.0中得到了发展。JDO似乎已经失去了发展动力。

都不行！

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

Objectify是专门为Google App Engine数据存储区设计的Java数据访问API。它占据了“中间地带”。与JDO或JPA相比，它更易于使用且更加透明，但比Low-Level 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);