我想用 Struts2 在 Google App Engine 上开发我的项目。对于数据库,我有两个选项 JPA 和 JDO。你们会建议我吗?两者对我来说都是新的,我需要学习它们。所以我会在你回复后专注于一个。
谢谢。
我想用 Struts2 在 Google App Engine 上开发我的项目。对于数据库,我有两个选项 JPA 和 JDO。你们会建议我吗?两者对我来说都是新的,我需要学习它们。所以我会在你回复后专注于一个。
谢谢。
GAE/J google 小组有几篇关于这件事的帖子。我会在那里搜索并查看人们的意见。你会得到与上述观点截然不同的信息。还要关注 BigTable 不是 RDBMS 的事实。为工作使用正确的工具
JPA 是 Sun 的持久性标准,JDO 恕我直言正在消亡(实际上,它已经消亡但仍在移动)。换句话说,从长远来看,JPA 似乎是一项更好的投资。所以我想如果两者对我来说都是新手,我会选择 JPA。
刚刚看到 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 的大力支持者,但我怀疑他是否有足够的偏见撒谎。
的确,当本书出版时,大多数主要供应商都团结在 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。
作为记录,它是 Google App Engine (GAE),所以我们使用 Google 规则而不是 Oracle/Sun 规则。
在它之下,JPA 不适合 GAE,它不稳定并且不能按预期工作。谷歌都不愿意支持它,但最低限度。
在其他方面,JDO 在 GAE 中相当稳定,并且(在某种程度上)被谷歌很好地记录在案。
但是,谷歌不推荐其中任何一个。
http://code.google.com/appengine/docs/java/datastore/overview.html
低级 API 将提供最佳性能,而 GAE 就是关于性能的。
例如,添加 10 个实体
蟒蛇:68毫秒
JDO:378ms
Java 原生:30 毫秒
在 JDO 与 JPA 之间的比赛中,我只能同意 datanucleus 海报。
首先,也是最重要的,datanucleus 的发布者知道他们在做什么。毕竟他们正在开发一个持久库,并且熟悉关系以外的数据模型,例如大表。我确信 id 是 hibernate 的开发人员,他会说:“我们在构建核心库时的所有假设都与关系模型紧密耦合,hibernate 没有针对 GAE 进行优化”。
其次,毫无疑问,JPA 的使用范围更广,成为官方 Java EE 堆栈的一部分会有所帮助,但这并不一定意味着它更好。事实上,如果您阅读过 JDO,它对应于比 JPA 更高级别的抽象。JPA 与 RDBMS 数据模型紧密耦合。
从编程的角度来看,使用 JDO API 是一个更好的选择,因为您在概念上的妥协要少得多。理论上,您可以切换到您想要的任何数据模型,前提是您使用的提供程序支持底层数据库。(实际上,您很少能达到如此高的透明度,因为您会发现自己在 GAE 的对象上设置了主键,并且您会将自己绑定到特定的数据库提供商,例如 google)。不过,迁移仍然会更容易。
第三,您可以在 GAE 中使用 Hibernate、Eclipse Link,甚至 Spring。谷歌似乎做了很大的努力来允许你使用你用来构建应用程序的框架。但是当人们像在 RDBMS 上运行一样构建 GAE 应用程序时,他们意识到它们很慢。GAE 上的春天很慢。您可以在此主题上搜索 Google IO 视频,看看是否属实。
此外,坚持标准是一件明智的事情,原则上我对此表示赞赏。另一方面,作为 Java EE 堆栈的一部分的 JPA 有时会让人们失去他们的选项概念。如果您愿意,请意识到 Java Server Faces 也是 Java EE 堆栈的一部分。对于 Web GUI 开发来说,它是一个令人难以置信的整洁解决方案。但最后,为什么人们,如果我可以这么说的话,更聪明的人,会偏离这个标准而使用 GWT?
在所有这些中,我必须说明 JPA 有一件非常重要的事情。这就是 Guice 及其对 JPA 的便捷支持。似乎谷歌在这一点上不像往常那样聪明并且满足,目前不支持 JDO。我仍然认为他们负担得起,最终 Guice 也会吞并 JDO,……或者可能不会。
去 JDO。就算没有这方面的经验,上手也不难,而且还会有新技能!
What I think is terrible about using JDO
at the time of writing this is that the only implementation vendor is Datanucleus
and the drawbacks of that is the lack of competition which leads to numerous issues like:
extensions
StackOverflow
I'm always hoping for someone to start implementing the JDO
specification themselves, may be then they'll offer something more and hopefully more free attention to the community and not always bothering about being paid for support, not saying that Datanucleus
authors only care about commercial support, but I'm just saying.
I personally consider Datanucleus
authors has no obligation whatsoever to Datanucleus
itself nor it's community. They can drop the whole project at anytime and no one can judge them for it, it's their effort and their own property. But you should know what you are getting into. You see, when one of us developers look for a framework to use, you cannot punish or command the framework's author, but on the other hand, you need your work done ! If you had time to write that framework, why would you look for one in the first place ?!
On the other hand, JDO
itself has some complications like objects life cycle and stuff which isn't very intuitive and common (I think).
Edit: Now I know also JPA
enforces the object life cycle mechanism, so it looks like its inevitable to deal with persisted entities life cycle states if you wish to use a standard ORM API (i.e. JPA
or JDO
)
What I like most about JDO
is the ability to work with ANY database management system without considerable effort.
GAE/J 计划在今年年底之前添加 MYSQL。
JPA is the way to go as it seems to be pushed as a standardized API and has recently got momentum in EJB3.0.. JDO seems to have lost the steam.
两者都不!
使用 Objectify,因为它更便宜(使用更少的资源)并且速度更快。仅供参考: http: //paulonjava.blogspot.mx/2010/12/tuning-google-appengine.html
Objectify 是专为 Google App Engine 数据存储设计的 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);