RestyGWT与RequestFactory

时间:2011-11-25 14:59:30

标签: performance json gwt rpc requestfactory

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

改变的主要原因是:

  • TypeSerializers消耗了应用代码大小的最大部分。
  • 客户端的序列化/反序列化特别是在开发模式下SLOW,这似乎是GWT-RPC的常见事实。
  • 显然我想尽量减少在线有效载荷,但这并不是一项艰难的要求。

我正在考虑的选项是:

  • RequestFactory,被提升为更快的野兽。但是我担心将域对象的客户端代码中的所有引用替换为它们的代理对应物会是很多工作,而且我也懒得实际构建所有代理。

  • 使用RestyGWT的完整JSON / REST方法,看起来它会让我仍然使用域对象,但我担心它最终会导致更慢的反序列化?我不是基于任何事实,但找不到任何基准。这只是一种印象。

我真的很想得到建议。

谢谢!

1 个答案:

答案 0 :(得分:1)

虽然我们目前正在使用RequestFactory,但我建议使用REST。 以下是以下三个主要原因:

  1. 客户端和服务器实现不必依赖(如果您计划使用非Android设备的本机应用程序而不是忘记requestfactory)。
  2. 在requestfactory中断旧客户端代码中的新api更改(这对生产有破坏性的结果)
  3. REST生态系统和社区规模更大,更容易解决代码中的问题,并允许其他应用程序在未来与您进行通信。