添加 Google App Engine 支持并保持独立支持答案

【问题标题】：Adding Google App Engine support and keeping standalone support添加 Google App Engine 支持并保持独立支持
【发布时间】：2011-01-03 13:44:43
【问题描述】：

我有一个基于 Stuts2/Google Guice/JPA 构建的 java web 应用程序。它使用休眠作为 JPA 供应商。我想添加支持，以便可以在 Google 的 App Engine 上使用。当然，我遇到了查询和映射的问题。例如不支持多对多和连接。

我正在尝试提出让我的应用程序能够独立运行的最佳解决方案。例如，在 JPA 供应商支持的任何数据库或以 datanucleus 作为供应商的 Google App Engine 上创建一个 tomcat/jetty。

我想到的一个解决方案是将 JPA 用于我的独立实现，将 JDO 用于 Google 的 App Engine。显然，这需要我用 JPA 和 JDO 注释来注释我的模型对象，并为 DAO 层编写另一个实现。

还有其他人尝试过的好的解决方案吗？

【问题讨论】：

标签： java google-app-engine jpa jdo

【解决方案1】：

您可以将查询重新定位到 XML 配置。这样，您可以在一个配置中查询 RDBMS，并在另一种配置中查询 BigTable。

另一个想法是 DataNucleus 也是 JPA 供应商。您可以通过将其设为 GAE 和 Servlet 容器上的主要 JPA 供应商来简化您的开发。 JPA 供应商通常在他们处理元数据的方式之间存在非常细微的差异，这可能会为您省去一些麻烦。

【讨论】：

不幸的是，GAE 现在无法处理多对多关系。您可以做的最好的事情是在每个类上携带键的集合并在您的 DAO/Service 层中处理这些集合。如果您擅长仅通过 DAO/Service 层访问事物，而不是大量的属性访问（Service.getContactByCategory(category) 而不是 category.getContacts()），那么您应该能够重新实现 DAO 以便它加载打电话时的钥匙。
这是一个现有的应用程序，不能像您建议的那样使用该服务。无论哪种方式，我都必须有不同的服务实现，所以不仅仅是将查询放在不同的 XML 文件中。

【解决方案2】：

我认为你的方法很好。我认为良好的设计架构是最好的方法。您很可能会在 DAO 层中看到很多差异。一个好的设计会看到一个 DAO 接口，然后每个特定的模型访问都会有它自己的该接口的实现，例如JpaMyObjectDAO、JpaGAEObjectDAO 等。也像您一样，App Engine 在声明实体类时有一些特殊要求。也许您可以拥有不同版本的实体类（每个都符合其存储方案，如 App Engine 或 Hibernate），然后有一个通用 DTO 表示供您的更高层使用。

【讨论】：

我已经很好地分离了 DAO 接口和服务接口，因此更改实现相当容易。看起来这就是我要走的路。我仍在考虑使用 DTO 对象而不是我的模型对象。现在我一直使用模型对象到视图。