什么时候应该使用RequestFactory vs GWT-RPC？

我试图弄清楚是否应该将gwt rpc调用迁移到新的GWT2.1 RequestFactory CAL

Google文档模糊地提到RequestFactory是“面向数据的服务”的更好的客户机-服务器通信方法

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

---

这就是问题的关键还是我遗漏了一些重要的东西？

我认为如果客户端有一个很重的pojo，例如如果您使用Hibernate或JPA实体，这会非常有用。

---

我们采用了另一种解决方案，使用Django风格的持久性框架，具有非常轻的实体。

我发现为所有实体创建代理类的想法非常烦人。我的Hibernate/JPAPoJO是从数据库模型自动生成的。为什么我现在需要为RPC创建第二个镜像？我们有一个很好的“估计”框架，负责POJO的“去休眠”

---

另外，定义服务接口的想法并不是将服务器端服务完全实现为java契约，而是实现方法——对我来说，这听起来非常像J2EE1.x/2.x

我要提出的唯一警告是RequestFactory使用二进制数据传输（可能是deRPC？），而不是普通的GWT-RPC

---

只有当您使用SyncProxy、Jmeter、Fiddler或任何类似工具（如GWT-RPC）进行大量测试时，这一点才有意义，因为这些工具可以读取/评估HTTP请求/响应的内容，但使用deRPC或RequestFactory会更具挑战性“按具体类型RPC”，而RequestFactory是“按接口RPC”

RPC更便于入门，因为您编写的代码行更少，并且在客户端和服务器上使用相同的类。您可以创建一个

Person

类，其中包含一组getter和setter，还可以创建一些简单的业务逻辑，用于进一步切片和切割

Person

对象中的数据在你想要在你的类中包含特定于服务器的、不兼容GWT的代码之前，RPC是非常好的。因为RPC系统基于客户端和服务器上具有相同的具体类型，所以你可以根据GWT客户端的功能来撞上一堵复杂的墙

为了避免使用不兼容的代码，许多用户最终创建了一个对等的

PersonDTO

，它隐藏了服务器上使用的真实

Person

对象。这个

PersonDTO

只有服务器端域的getter和setter的子集“，

人

对象。现在，您必须编写代码，在

Person

和

PersonDTO

对象与要传递给客户端的所有其他对象类型之间封送数据

RequestFactory首先假设域对象不兼容GWT。您只需在代理接口中声明客户端代码应该读取和写入的属性，RequestFactory服务器组件负责封送数据并调用您的服务方法。对于具有定义良好的“实体”或“具有标识和版本的对象”概念的应用程序，

EntityProxy

类型用于向客户端代码公开数据的持久标识语义。使用

ValueProxy

类型映射简单对象

---

使用RequestFactory，您需要预先支付启动成本，以适应比GWT RPC容易支持的更复杂的系统。RequestFactory的

ServiceLayer

通过添加实例提供了更多的钩子来定制其行为。

我们的项目中有一个非常大的GWT-RPC实现。 事实上，我们有50个服务接口，每个接口都有许多方法，而且编译器生成的TypeSerializer的大小使我们的JS代码变得庞大，我们遇到了一些问题。 因此，我们正在分析如何向工厂迈进。 我已经读了好几天了，我深入网络，试图找到其他人在做什么。 我看到的最重要的缺点（也许我错了）是，使用RequestFactory，您不再控制服务器域对象和客户端对象之间的通信。 我们需要的是以可控的方式应用加载/保存模式。我的意思是，例如，客户机接收属于特定事务的对象的整个对象图，进行更新，然后将整个对象图发送回服务器。服务器将负责执行验证、新旧值比较和持久性。如果来自不同站点的两个用户获得相同的事务并进行了一些更新，则生成的事务不应是合并的事务。在我的场景中，其中一个更新应该失败。 我不认为RequestFactory有助于支持这种处理

问候

---

Daniel

公平地说，当考虑一个有限的MIS应用程序时，比如10-20个可损坏的业务对象，每个对象都有~1-10个属性，这真的取决于个人偏好选择哪条路径

如果是这样，那么预测应用程序将如何扩展可能是选择路由GWT RPC或RequestFactory的关键：

我的应用程序预计将保留在数量相对有限的实体中，但其数量将大幅增加。10-20个对象*100000条记录

我的申请将在实体的广度上显著增加，但每个实体所涉及的相对数量仍然很低。5000个对象*100条记录

我的应用程序预计将保留在数量相对有限的实体中，并保留在数量相对较少的实体中，例如10-20个对象*100个记录

就我而言，我在