3

我们正在尝试使用RequestFactory现有的 Java 实体模型。我们的 Java 实体都实现了一个DomainObject接口并公开了一个getObjectId()方法（这个名称被选择为getId()可能是模棱两可的，并且与正在建模的域中的域对象的实际ID 冲突。

该ServiceLayerDecorator接口允许自定义 ID 和版本属性查找策略。

public class MyServiceLayerDecorator extends ServiceLayerDecorator {
    @Override
    public Object getId(Object object) {
        DomainObject domainObject = (DomainObject) object;
        return domainObject.getObjectId();
    }
}

到现在为止还挺好。但是，尝试部署此解决方案会产生运行时错误。特别是RequestFactoryInterfaceValidator抱怨：

[ERROR] There is no getId() method in type com.mycompany.server.MyEntity

然后稍后：

[ERROR] Type type com.mycompany.client.MyEntityProxy was previously marked as bad
[ERROR] The type com.mycompany.client.MyEntityProxy did not pass RequestFactory validation
[ERROR] Unexpected error
com.google.web.bindery.requestfactory.server.UnexpectedException: The type com.mycompany.client.MyEntityProxy did not pass RequestFactory validation
    at com.google.web.bindery.requestfactory.server.ServiceLayerDecorator.die(ServiceLayerDecorator.java:212) ~[gwt-servlet.jar:na]

我的问题是 - 如果硬编码和的约定，为什么ServiceLayerDecorator允许自定义 ID 和版本查找策略？RequestFactoryInterfaceValidatorgetId()getVersion()

我想我可以重写ServiceLayerDecorator.resolveClass()以忽略“中毒”代理类，但在这一点上，我似乎在与框架作斗争太多......

4

1 回答 1

3

几个选项，其中一些已经被提及：

  • Locator. 我喜欢为整个项目制作一个定位器，或者至少为具有相似键类型的相关对象组制作一个定位器。getId() 调用将能够调用您的 DomainObject.getObjectId() 方法并返回该值。请注意，该getDomainType()方法当前未使用，可以返回 null 或引发异常。
  • ValueProxy. 与其将您的对象映射到 RF 可以理解为实体的东西，不如将它们映射到纯值对象 - 不需要 id 或版本。RF 错过了它可以做的许多聪明的事情，尤其是在避免向服务器发送冗余数据方面。
  • ServiceLayerDecorator. 这在 2.4 之前有效，但随着现在进行的注释处理，它的效果不太好，因为它试图为你做一些工作。似乎 ServiceLayerDecorator 在过去几个月中失去了很多优势 - 理论上，您可以使用它来重建 getter 以直接与您的持久性机制对话，但现在注释处理验证了您的代码，这不再是一种选择.

所有这一切的大问题是 RequestFactory 旨在解决单个问题，并且很好地解决它：允许开发人员使用映射到某些持久性机制的 POJO，并从客户端引用这些对象，遵循某些约定以避免编写额外的代码或配置。

结果，它很好地解决了自己的问题，最终不适合许多其他问题/用例。您可能会发现它不值得：如果是这样，您可能会考虑以下几点：

  • RPC。它在很多方面并不完美，但它在很多方面都做得很好。
  • AutoBeans（RF 所基于）仍然是一种通过网络发送数据并将其输入应用程序的非常快速、轻量级的方式。您可以围绕它构建自己的包装器，就像 RF 所做的那样，并将它试图解决的问题缩小到您的用例。
于 2011-11-08T16:15:42.470 回答