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

Question

我试图找出是否应该将我的gwt-rpc调用迁移到新的GWT2.1 RequestFactory cals.

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

我可以从文档中提炼出来的是有一个新的Proxy类可以简化通信(你不会来回传递实际的实体而只是代理,所以它更轻,更容易管理)

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

Answer 1

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

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

为了避免使用不兼容的代码,许多用户最终会创建一个对等体PersonDTO,该对等体会遮蔽Person服务器上使用的真实对象.在PersonDTO刚刚拥有服务器端的getter和setter,"域",的一个子集Person的对象.现在,你必须编写代码的之间马绍尔群岛数据Person和PersonDTO对象,并要传递给客户端的所有其他对象类型.

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

使用RequestFactory,您需要支付前期启动成本,以适应比GWT RPC轻松支持的更复杂的系统.RequestFactory ServiceLayer提供了更多的钩子来通过添加ServiceLayerDecorator实例来定制其行为.

Answer 2

我经历了从RPC到RF的过渡.首先,我必须说我的经验是有限的,我使用了尽可能多的EntityProxies.

GWT RPC的优点:

• 设置,理解和学习都很容易!
• 在客户端和服务器上使用相同的基于类的对象.
• 这种方法可以节省大量代码.
• 理想的是,当在客户端和服务器上使用相同的模型对象(和POJOS)时,POJO == MODEL OBJECTs == DTOs
• 易于从服务器移动到客户端.
• 易于在客户端和服务器之间共享通用逻辑的实现(当您需要不同的逻辑时,这可能会成为一个关键的缺点).

GWT RPC的缺点:

• 不可能为服务器和客户端实现某些方法的不同实现,例如,您可能需要在客户端和服务器上使用不同的日志记录框架,或者使用不同的equals方法.
• 真正糟糕的实现,无法进一步扩展:大多数服务器功能都是作为RPC类的静态方法实现的.真的很糟糕.
• 例如,无法添加服务器端错误混淆
• 一些安全性XSS问题不是很优雅可解,请参阅docs(我不确定这对RequestFactory来说是否更优雅)

RequestFactory的缺点:

• 真的很难从官方文档中了解到它的优点是什么!它始于完全误导性的术语PROXIES - 这些实际上是由RF自动创建的RF的DTO.代理由接口定义,例如@ProxyFor(Journal.class).IDE检查Journal上是否存在相应的方法.这么多的映射.
• 就客户端和服务器的共性而言,RF对您没有太大作用
• 在客户端上,您需要将"PROXIES"转换为客户端域对象,反之亦然.这完全是荒谬的.它可以在几行代码中以声明方式完成,但是没有任何支持!如果我们能够更优雅地将我们的域对象映射到代理,那么像JavaScript方法JSON.stringify(.. ,,)这样的东西在RF工具箱中就是MISSING.
• 不要忘记,您还负责将域对象的可转移属性设置为代理,依此类推.
• 服务器上的错误处理错误 - 默认情况下,服务器上省略了堆栈跟踪,并且您在客户端上获得空的无用异常.即使我设置自定义错误处理程序,我也无法获得低级别的堆栈跟踪!可怕.
• IDE支持和其他地方的一些小错误.我提交了两个被接受的错误请求.不是爱因斯坦需要弄清楚那些实际上是错误.
• 文件说.正如我所提到的,应该更好地解释代理,这个术语是MISLEADING.对于我正在解决的基本常见问题,DOCS是无用的.来自DOC的误解的另一个例子是JPA注释与RF的连接.从简洁的文档看,它们有点一起玩,是的,StackOverflow上有一个相应的问题.我建议在理解RF之前忘记任何JPA'连接'.

RequestFactory的优点

• 优秀的论坛支持.
• IDE支持非常好(但与RPC相比并不是一个优势)
• 客户端和服务器实现的灵活性(松散耦合)
• 除了简单的DTO之外,连接到EntityProxies的花哨的东西 - 缓存,部分更新,对移动设备非常有用.
• 您可以使用ValueProxies作为DTO的最简单替代品(但您必须自己完成所有不那么花哨的转换).
• 支持Bean验证JSR-303.

综合考虑GWT的其他缺点:

• 无法使用提供的JUnit支持运行集成测试(GWT客户端代码+远程服务器)<=必须模拟所有JSNI(例如localStorage),SOP是一个问题.

• 不支持测试设置 - 无头浏览器+远程服务器<=没有简单的无头测试GWT,SOP.

• 是的,可以运行selenium集成测试(但这不是我想要的)

• JSNI是非常强大的,但是在他们在会议上提出的那些闪亮的会谈中,他们并没有多说写JSNI代码也有一些规则.再次,弄清楚如何编写一个简单的回调是一个值得真正研究者的任务.

总之,当RPC主要满足您的需求时,从GWT RPC到RequestFactory的转换远非WIN-WIN情况.您最终会将客户端域对象的吨转换写入代理,反之亦然.但是,您可以获得解决方案的一些灵活性和稳健性.星期六,论坛上的支持也很棒!

考虑到我刚才提到的所有优点和缺点,事先考虑这些方法中的任何一种是否真正改善了您的解决方案和您的开发设置而没有大的权衡取舍,这是非常好的.

Answer 3

我发现为我的所有实体创建代理类的想法非常烦人.我的Hibernate/JPA pojos是从数据库模型自动生成的.为什么我现在需要为RPC创建第二个镜像？我们有一个很好的"estivation"框架,负责"去冬眠"pojos.

另外,定义服务接口的想法并没有完全实现服务器端服务作为java合同但是实现了这些方法 - 对我来说听起来非常J2EE 1.x/2.x.

Answer 4

我认为如果您在客户端有大量的 pojo，例如如果您使用 Hibernate 或 JPA 实体，那么这确实很有帮助。我们采用了另一种解决方案，使用 Django 风格的持久性框架和非常轻的实体。