Google App Engine上的JDO与JPA for Java

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

谢谢。

Answer 1

JPA是Sun的持久标准，JDO是IMHO的死亡（实际上，它已经死了，但仍在移动）。 换句话说，JPA似乎是一个长期的更好的投资。 所以我想我会selectJPA，如果这两个对我来说都是新手。

Answer 2

GAE / J谷歌组有几个关于这个事情的post。 我会在那里search，看看人们的意见。 你会得到一个非常不同的信息，以上expression的意见。 还要关注BigTable不是RDBMS的事实。 使用正确的工具来完成这项工作

Answer 3

刚刚看到JPN和JDO之间的DataNucleus自己比较： – http://www.datanucleus.org/products/accessplatform_2_1/jdo_jpa_faq.html一个大开眼界。;

Answer 4

我是JDO的一个快乐的用户。 保持良好的工作人员。

Answer 5

声称JDO已经死了的人不是没有道理的。 以下是我在“专业EJB 3 Java持久性API”一书中读到的内容：“不久之后，Sun宣布将JDO简化为规范维护模式，并且Java持久性API将从JDO和其他持久性供应商中抽取出来，并成为单一支持标准前进“。 作者Mike Keith是EJB3的共同规范领导者。 当然他是JPA的大力支持者，但是我怀疑他是否有足够的偏见来说谎。

诚然，当这本书出版时，尽pipeJDO比JPA拥有更先进的技术特性，但大多数主要厂商都联合在JPA之后，而不是JDO。 这并不奇怪，因为在EE这个世界里，像IBM / Oracle这样的大公司也是大型的RDBMS供应商。 更多的客户在其项目中使用RDMBS而不是非RDMBS。 JDO正在死亡，直到GAE给它一个很大的提振。 这是有道理的，因为GAE数据存储不是关系数据库。 某些JPAfunction不适用于聚合查询，Join查询等拥有多对多关系的bigtable。 顺便说一下，GAE支持JDO 2.3，而只支持JPA 1.0。 如果GAE是您的目标云平台，我会推荐JDO。

Answer 6

为了logging，它是Google App Engine（GAE），所以我们使用Google规则而不是Oracle / Sun规则。

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

而对于其他部分，JDO在GAE中相当稳定，并且（在某种程度上）由Googlelogging。

不过，Google不会推荐其中的任何一个。

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

低级别的API会提供最好的性能，而GAE则是性能。

http://gaejava.appspot.com/

例如，添加10个实体

Python：68ms

JDO：378ms

Java本机：30毫秒

Answer 7

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

首先，也是最重要的，数据中心的海报知道他们在做什么。 他们毕竟是在开发一个持久的库，并且熟悉关系之外的数据模型，比如Big Table。 我确信hibernate的开发人员在这里，他会说：“我们所有的构build核心库的假设都与关系模型紧密结合，hibernate没有针对GAE进行优化”。

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

从编程的angular度来看，使用JDO API是一个更好的select，因为你在概念上减less了很多。 只要您使用的提供程序支持底层数据库，您可以在理论上切换到任何您想要的数据模型。 （在实践中，你很less达到如此高的透明度，因为你会发现自己在GAE的对象上设置你的主键，你会绑定到一个特定的数据库提供商，如谷歌）。 它仍然会更容易迁移。

第三，您可以使用Hibernate，Eclipse Link，甚至GAE弹簧。 谷歌似乎已经做了很大的努力，让你使用你用来构build应用程序的框架。 但是，当他们将自己的GAE应用程序构build为运行在RDBMS上时，人们意识到的是它们很慢。 GAE的spring很慢。 您可以在这个主题上谷歌谷歌IOvideo，看看这是真的。

而且，坚持标准是一个很明智的做法，原则上我鼓掌。 另一方面，作为Java EE栈的一部分的JPA使得人们有时会失去select的概念。 意识到，如果您愿意，Java Server Faces也是Java EE堆栈的一部分。 这是一个令人难以置信的Web GUI开发解决scheme。 但最后，为什么人们，更聪明的人，如果我可以这样说，偏离了这个标准，而使用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或JDO ），看起来像处理持久化实体生命周期状态是不可避免的。

我最喜欢JDO是能够在没有相当多的努力的情况下使用任何数据库pipe理系统。

Answer 10

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

Answer 11

JPA是要走的路，因为它似乎被当作一个标准化的API来推动，并且最近在EJB3.0中获得了动力.JDO似乎已经失去了动力。

Answer 12

都不是！

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

Objectify是专门为Google App Engine数据存储devise的Java数据访问API。 它占据了“中间地带”; 比JDO或JPA更易于使用和更透明，但比低级API方便得多。 Objectify旨在使新手立即生产，同时也暴露GAE数据存储的全部力量。

Objectify可以让你坚持，检索，删除和查询你自己的types对象。

 @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);