GWT 编辑器和 GAE 数据存储答案

【问题标题】：GWT Editors and GAE DatastoreGWT 编辑器和 GAE 数据存储
【发布时间】：2012-10-11 05:35:21
【问题描述】：

GWT 有一个Editor Framework，粗略检查后，它看起来非常像 Spring MVC/Forms 处理后端数据对象和前端 UI 组件之间的数据绑定的方式。

我正在编写我的第一个 GWT/GAE 应用程序，想知道是否有任何方法可以将此编辑器框架与 GAE 的 JDO/Atomic 库结合使用，该库是您针对 O 编写的 API /R 在您的应用和底层数据存储之间映射。

这两个框架是互补的还是相互排斥的？如果他们可以一起工作，有人可以提供一个小代码示例，说明我如何使用它们来填充，例如，带有名称列表的 HTML <select> 框，或者其他基本但实用的东西。

我想这可能涉及一个代表一个人的Person POJO（并具有一个String name 属性），也许是某种PersonDAO，它使用JDO/Atomic 来CRUD Person 实例到/来自数据存储区，然后是某种Editor<Person> 可以将Person 实例映射到前端<select>s。

如果我能看到一个可行的例子，我想这一切都会为我而存在。而且，如果这些是相互排斥的并且不能一起使用，那么非常会非常感谢您对原因的可靠解释！提前致谢！

【问题讨论】：

你没有提到 Objectify，但是这篇关于将它与编辑器框架集成的博文非常棒：turbomanage.wordpress.com/2011/03/25/…
啊，所以看起来 Objectify 是 JDO/Atomic 的包装器？有点像 Hibernate 如何包装 JDBC？谢谢@ben_w！
Objectify 与 JDO 无关，它是 JDO 的替代品。不知道你指的这个“原子”是什么。

标签： java google-app-engine gwt google-cloud-datastore jdo

【解决方案1】：

我希望这会有所帮助，这是一些将数据存储在 GAE 数据存储中的示例代码，一个用于获取数据并使用内容填充 GWT 下拉列表的简单查询。

这是一个持久保存到应用引擎数据存储区的 JDO ORM：

https://github.com/bsautner/com.nimbits/blob/master/nimbits-tds/src/com/nimbits/server/orm/EntityStore.java

这是一个查询数据存储以获取对象列表的示例

@Override
    public List<Entity> getEntityByName(final User user, final String name) 
{
        final PersistenceManager pm = pmf.getPersistenceManager();

        try {
            final Query q1 = pm.newQuery(EntityStore.Class);
            final List<Entity> c;

                q1.setFilter("name==b");
                q1.declareParameters("String b");
                q1.setRange(0, 1);
                c = (List<Entity>) q1.execute(name);

            if (c.isEmpty()) {
                return Collections.emptyList();
            } else {

                final Entity result = c.get(0);
                return createModel(user, result);

            }

        } finally {
            pm.close();
        }
    }

这是一个基于 GWT (GXT) 的组合框，其中填充了从 ORM 模型创建的 POJO

https://github.com/bsautner/com.nimbits/blob/master/nimbits-tds/src/com/nimbits/client/ui/controls/EntityCombo.java

【讨论】：

【解决方案2】：

在 IE6 和 HTML4 时代，没有办法编写像 GMail 一样酷的 Web 应用程序。这就是引入 GWT 并实现目标的原因：GMail 能够在任何浏览器中工作。

在我们的时代，GWT 似乎失去了领导地位。 jQuery 变得越来越流行，因为它使用硬件加速并且运行速度更快......但是现在忘记 GWT 还为时过早。

如果你想使用 Editor 框架和 JDO，那么我们需要强调它们之间存在一个瓶颈：GWT RPC。 RPC 每次都对 POJO 进行序列化和反序列化，而您自定义这种序列化/反序列化的方法非常有限。

GWT RPC 的这个缺点迫使大多数开发人员维护两个相同的 POJO 层次结构：一个用于 JDO/Hibernate，第二个用于 GWT。通常老板会批准这个解决方案，因为它比绕过每个 RPC 调用来使其工作更快、更容易。在我见过的大多数现实世界项目中，都有两个层次结构......

另一方面，jQuery 根本不需要定义任何 POJO。显然这是发展速度不同的一个原因。

很抱歉，我没有提供任何答案。我希望我的想法是有用的，即使它只是说你在死胡同里。而且我已经多次看到经验丰富的建筑师决定使用 GWT 并且也进入了这条死胡同。而现在他们通过花费时间和金钱编写两个相同的 POJO 层次结构来为这个错误付出代价。

【讨论】：