RestyGWT 与 RequestFactory答案

【问题标题】：RestyGWT vs RequestFactoryRestyGWT 与 RequestFactory
【发布时间】：2012-01-06 10:30:35
【问题描述】：

我正在考虑将我当前基于 GWT-RPC 的服务层迁移到其他东西。它大约有 10 个服务接口，每个接口有 5 个方法，涉及大约 20 个不同的域实体，因此您对更改整个事物所需的工作量有所了解，显然我希望将其最小化。我还使用 Gilead 和基于 Guice 的集中式 Servlet 来处理所有 RPC 请求。

改变的主要原因是：

TypeSerializer 占用了应用代码的大部分大小。
客户端的序列化/反序列化在开发模式下特别慢，这似乎是 GWT-RPC 的普遍事实。
显然我想尽量减少在线负载，但这不是硬性要求。

我正在考虑的选项是：

RequestFactory，被提升为更快的野兽。但是我担心将域对象的客户端代码中的所有引用替换为它们的代理对应物会做很多工作，而且我也懒得实际构建所有代理。
使用 RestyGWT 的完整 JSON/REST 方法，看起来它可以让我仍然使用域对象，但我担心它最终会导致反序列化更慢？我不是基于任何事实，但找不到任何基准。这只是一个印象。

我真的很想得到建议。

谢谢！

【问题讨论】：

要考虑的另一件事是，完整的 JSON/REST 方法允许其他客户端更轻松地与您的服务器交互。
确实如此，并且支持 JSON/REST。但我现在更关心性能。此外，我还计划使用 GWT 开发移动客户端，所以在我未来很远的本地化之前，我可以使用仅适用于 GWT 的服务层。
您考虑过使用 GWT 覆盖类型吗？它们具有非常低的反序列化成本（几乎按照定义）。
@Hbf 是的，但是这样做我应该为我的客户端代码而不是我的服务器代码创建单独的模型/域对象，因为它们必须扩展 JavascriptObject。使用 RestyGWT 的要点之一是保持双方使用相同的对象，因为两个代码库都希望携带和使用这些对象。
@triforce：我明白了，这是有道理的。 – 在某些项目中，我发现自己使用 DTO 的频率比发送实际对象的频率高得多。为了降低维护工作量，我研究了在编译时自动生成 DTO 和 Action/Result 类。这对我来说非常有效：静态类型来捕获错误，不需要为我编写样板代码。这是一种方法：code.google.com/p/gwt-platform/wiki/…，但我发现它不够灵活并开始自己编写。

标签： performance json gwt rpc requestfactory

【解决方案1】：

虽然我们目前正在使用 RequestFactory，但我推荐使用 REST。以下是 3 个主要原因：

客户端和服务器实现不必相互依赖（如果您计划为非 android 设备开发本机应用程序而不是忘记 requestfactory）。
requestfactory 中的新 api 更改会破坏旧客户端代码（这会对生产造成破坏性后果）
REST 生态系统和社区更大，更容易解决代码中的问题，并允许其他应用在未来与您的应用进行通信。

【讨论】：