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

问题描述

Google文档模糊地提到RequestFactory是一个包含所有新的GWT2.1 RequestFactory cals的应用程序。为面向数据的服务提供更好的客户端 - 服务器通信方法

我可以从文档中提取的是，有一个新的代理类可以简化通信（不要不会来回传递实际的实体，而只是代理，所以它更轻，更容易管理）

在大图中？

解决方案

GWT RPC和RequestFactory之间的最大区别在于RPC系统是通过具体RPC -type，而RequestFactory是RPC-by-interface。

RPC开始使用起来更方便，因为您编写的代码行较少，并且使用相同的类在客户端和服务器上。您可以使用一堆getter和setter创建一个 Person 类，也许可以使用一些简单的业务逻辑来进一步对中的数据进行切片和切分。人对象。这很好，直到你想要在你的类中有特定于服务器的，非GWT兼容的代码。由于RPC系统基于在客户端和服务器上都具有相同的具体类型，因此您可以根据GWT客户端的功能选择复杂墙。

为了避免使用不兼容的代码，许多用户创建了一个隐藏真实的 Person 对象的对等 PersonDTO 在服务器上。 PersonDTO 只是服务器端的get和setter的一个子集，domain， Person 对象。现在你必须编写一些代码来封装 Person 和 PersonDTO 对象和所有你想要的对象类型之间的数据传递给客户端。

RequestFactory首先假定您的域对象不会与GWT兼容。您只需声明代理接口中应由客户端代码读取和写入的属性，并且RequestFactory服务器组件负责封送数据并调用服务方法。对于具有实体或带有身份和版本的对象定义明确的概念的应用程序， EntityProxy 类型用于将数据的持久标识语义公开给客户端代码。使用 ValueProxy 类型映射简单对象。

通过使用RequestFactory，您可以支付预先启动成本以适应比GWT RPC容易支持的更复杂的系统。 RequestFactory的 ServiceLayer 通过添加 ServiceLayerDecorator 实例。

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

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

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?

解决方案

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 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.

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 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.

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屋！