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

Question

关于如何最好地访问 Google App Engine 数据存储区有什么建议吗？通过 JDO、JPA 还是原生 API？

JDO/JPA 的明显优势是可移植到其他数据库引擎，但除此之外，还有什么理由不直接使用 Datastore API？

Answer 1

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

您还可以找到大量关于 JDO 和 JPA 的简洁示例，它们几乎可以解决所有可能的场景here.

最后我会看看 Objectify 和 Twig，这两个显然很流行的替代框架，在我也在尝试做出这个决定时，question I asked 中提到了它们。

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

Answer 2

低级 Datastore API 并非旨在直接使用，而是为其他框架提供 API 以与数据存储区交互。

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

(source)

Objectify 是一个这样的框架，它是一个比 JDO 或 JPA 更简单的数据存储接口，并且在设计时只考虑了数据存储。

Answer 3

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

当然，您可以开始使用 JDO/JPA，如果您意识到需要更大的灵活性，您仍然可以重构代码的某些部分以使用低级函数。正如 tempy 所提到的，内部引用被保存为 ID（当然键也是如此）。

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

最后，如果您不确定，我认为这两种解决方案都是正确的选择。但是您应该真正查看可用的文档并阅读（博客）文章以了解最佳实践，无论您选择 JDO/JPA 还是低级。

菲利普