访问GAE数据存储:使用JDO、JPA还是低级API?

我对JPA不太了解,但我使用JDO,如果你是新手,我可以说它有一个相当陡峭的学习曲线和很多不适用于GAE的无关内容。你赢的是 owned relationships, 它允许您拥有彼此具有实际引用的类,而不仅仅是数据存储ID。JDO还可以通过注释做一些有用的事情,比如@Element(dependent=“true”)注释,这节省了您很多工作,因为它允许您删除父对象,JDO将删除其所有子对象。一般来说,GAE文档遗漏了许多有效使用JDO所需的知识,因此我认为阅读datanucleus文档并特别注意获取组是至关重要的。

您还可以为JDO和JPA找到大量简洁的示例,这些示例几乎可以解决所有可能的场景 here.

最后,我将看看Objectify和Twig,这两个显然很流行的替代框架,在 question I asked 当我也在做这个决定的时候。

另一方面,对于到其他数据库的可移植性,我认为担心GAE上的可移植性有点误导。尽管Google希望我们认为GAE代码是可移植的,但我认为这只是一个空想。最后,您将以Google提供的API的特定组合为目标进行编码,这种组合在其他地方可能看不到,并且还将围绕GAE的许多限制和特性进行编码,因此,我将忘记将可移植性作为确定数据访问API的一个因素。事实上,如果我能重新做出我在这件事上的决定,我想我会使用一个专门为GAE构建的数据访问框架,比如objectify。

低级数据存储API不是设计用来直接使用的,而是为其他框架提供与数据存储交互的API。

这个包包含一个数据存储的低级API,主要用于框架作者。应用程序作者应该考虑使用提供的JDO或JPA接口。

( source )

一个这样的框架是 Objectify ,这是一个比JDO或JPA更简单的数据存储接口,而且是一个只考虑数据存储的接口。

我想这是口味的问题。ORM解决方案(JDO/JPA)通常是更舒适的解决方案。另一方面,低级API允许完全灵活,不受ORM的任何限制的限制。当然,您需要编写更多的代码,并且可能需要编写自己的数据存储抽象层。但如果以后需要优化某些东西,这可能会变得很方便。

当然,你可以开始使用JDO/JPA,如果你认识到你需要更多的灵活性,你仍然可以重构你的代码的某些部分来使用低级函数。正如tempy所提到的,内部引用被保存为id(当然键也是一样的)。

一般来说(在SQL世界中)很多人说,通过使用低级的东西,您可以了解更多关于数据库的信息,从而对优化有更好的感觉。有很多人使用ORMs,但是使用效率很低,因为他们认为ORM为他们做了所有的工作。因此,它们会遇到性能或维护问题。

最后,如果你不确定的话,我认为这两种方法都是正确的选择。但是您应该查看可用的文档并阅读(blog)文章来了解最佳实践,无论您选择JDO/JPA还是低级的。

菲利普