我应该什么时候使用 RequestFactory 和 GWT-RPC? [英] When should I use RequestFactory vs GWT-RPC?

问题描述

我想知道是否应该将我的 gwt-rpc 调用迁移到新的 GWT2.1 RequestFactory cals.

I am trying to figure out if I should migrate my gwt-rpc calls to the new GWT2.1 RequestFactory cals.

Google 文档含糊地提到 RequestFactory 是一种更好的面向数据的服务"的客户端-服务器通信方法

Google documentation vaguely mentions that RequestFactory is a better client-server communication method for "data-oriented services"

我可以从文档中提炼出的是，有一个新的 Proxy 类可以简化通信(您不会来回传递实际实体，而只会传递代理，因此重量更轻且更易于管理)

What I can distill from the documentation is that there is a new Proxy class that simplifies the communication (you don't pass back and forth the actual entity but just the proxy, so it is lighter weight and easier to manage)

这是重点还是我在大局中遗漏了其他东西?

Is that the whole point or am I missing something else in the big picture?

推荐答案

GWT RPC 和 RequestFactory 最大的区别在于 RPC 系统是RPC-by-concrete-type"，而 RequestFactory 是RPC-by-interface".

The big difference between GWT RPC and RequestFactory is that the RPC system is "RPC-by-concrete-type" while RequestFactory is "RPC-by-interface".

RPC 上手更方便，因为您编写的代码行更少，并且在客户端和服务器上使用相同的类.您可以创建一个 Person 类，其中包含一堆 getter 和 setter，可能还有一些简单的业务逻辑，以便进一步对 Person 对象中的数据进行切片和切块.这非常有效，直到您最终想要在您的类中包含特定于服务器的、非 GWT 兼容的代码.由于 RPC 系统基于在客户端和服务器上具有相同的具体类型，因此您可能会遇到基于 GWT 客户端功能的复杂性墙.

RPC is more convenient to get started with, because you write fewer lines of code and use the same class on both the client and the server. You might create a Person class with a bunch of getters and setters and maybe some simple business logic for further slicing-and-dicing of the data in the Person object. This works quite well until you wind up wanting to have server-specific, non-GWT-compatible, code inside your class. Because the RPC system is based on having the same concrete type on both the client and the server, you can hit a complexity wall based on the capabilities of your GWT client.

为了避免使用不兼容的代码，许多用户最终创建了一个对等 PersonDTO，它隐藏了服务器上使用的真实 Person 对象.PersonDTO 只有服务器端域"、Person 对象的 getter 和 setter 的一个子集.现在您必须编写代码，在 Person 和 PersonDTO 对象以及您想要传递给客户端的所有其他对象类型之间编组数据.

To get around the use of incompatible code, many users wind up creating a peer PersonDTO that shadows the real Person object used on the server. The PersonDTO just has a subset of the getters and setters of the server-side, "domain", Person object. Now you have to write code that marshalls data between the Person and PersonDTO object and all other object types that you want to pass to the client.

RequestFactory 开始时假设您的域对象不会与 GWT 兼容.您只需在 Proxy 接口中声明应该由客户端代码读取和写入的属性，RequestFactory 服务器组件负责整理数据并调用您的服务方法.对于具有明确定义的实体"或具有身份和版本的对象"概念的应用程序，EntityProxy 类型用于向客户端代码公开数据的持久身份语义.使用 ValueProxy 类型映射简单对象.

RequestFactory starts off by assuming that your domain objects aren't going to be GWT-compatible. You simply declare the properties that should be read and written by the client code in a Proxy interface, and the RequestFactory server components take care of marshaling the data and invoking your service methods. For applications that have a well-defined concept of "Entities" or "Objects with identity and version", the EntityProxy type is used to expose the persistent identity semantics of your data to the client code. Simple objects are mapped using the ValueProxy type.

使用 RequestFactory，您需要支付前期启动成本，以适应 GWT RPC 无法轻松支持的更复杂的系统.RequestFactory 的 ServiceLayer 通过添加 ServiceLayerDecorator 实例.

With RequestFactory, you pay an up-front startup cost to accommodate more complicated systems than GWT RPC easily supports. RequestFactory's ServiceLayer provides significantly more hooks to customize its behavior by adding ServiceLayerDecorator instances.

这篇关于我应该什么时候使用 RequestFactory 和 GWT-RPC?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！