Gwt 具有不可变ValueProxy属性的EntityProxy->&引用；找不到setter"；

我正试着把我的注意力集中在RequestFactory上，但我遇到了一些问题。我有一个entityproxy，它的属性是不可变类型（joda time LocalDate）的valueproxy，在对服务器的任何调用中使用该entityproxy都会遇到问题

通过在entityproxy中只包含属性的getter，并且在valueproxy中只包含基元属性的getter，我将属性设置为只读

但是，据我所知，如果在调用服务方法时使用entityproxy作为参数，任何引用的valueproxy都会自动标记为已编辑，并且其所有属性都包含在增量中

这反过来会导致ReflectiveServiceLayer抛出一个关于LocalDate上缺少setter的异常

我一直在考虑实现一个ServiceLayerDecorator来覆盖“setProperty”来解决这个问题，但我不确定这是否是一个好的解决方案。有什么“合适”的方法来解决这个问题吗？理想情况下，我希望AbstractRequestContext不要在对服务器的调用中包含不可变的属性

我正在使用GWT2.3

编辑：我创建了一个类似这样的解决方案，但我仍然不确定这是否是正确的方法：

public class ImmutablePropertyFixServiceLayer extends ServiceLayerDecorator {
    @Override
    public void setProperty(Object domainObject, String property, Class<?> expectedType, Object value) {
        Method setter = getTop().getSetter(domainObject.getClass(), property);
        if (setter != null) {
            super.setProperty(domainObject, property, expectedType, value);
        } else {
            //System.out.println(domainObject.getClass().getName() + "." + property + " doesn't have a setter");
        }
    }
}

公共类ImmutablePropertyFixServiceLayer扩展ServiceLayerCorator{
@凌驾
public void setProperty（对象域对象、字符串属性、类expectedType、对象值）{
方法setter=getTop（）.getSetter（domainObject.getClass（），属性）；
if（setter！=null）{
super.setProperty（domainObject，property，expectedType，value）；
}否则{
//System.out.println（domainObject.getClass（）.getName（）+“+property+”没有setter”）；
}
}
}

EntityProxy对象有一些方法可以在服务器上轻松检索，因此在将对象发送回服务器时，只需要ID即可。另一方面，ValueProxy对象只能作为其所有子值的组合发送。将不可变值发送回服务器时，服务器代码不知道如何将代理恢复为服务器端值

---

我很担心您的解决方案，您可能无法在服务器上正确获取与客户端发送的日期相同的日期。

谢谢您的回答。后来我跳过了使用RequestFactory，因为我发现我在如何实现域对象方面不断遇到限制，这首先扼杀了在某些DTO解决方案上使用RequestFactory的意义（这有意义吗？：）无论如何，我遇到的问题。。。在本例中，值代理对象被标记为已编辑，而它们本不应该被编辑。RF有一些机制只将差异更改发送回服务器，但这似乎只适用于原语属性，而没有扩展到值代理中的原语？在本例中，这是一个问题，因为服务器端的RF一直试图更改值代理所代表的不可变对象的属性。还有一条要澄清的注释：这些对象实际上都不是在客户端上创建的，因此，在任何情况下，忽略客户端提供的属性都不会导致不一致的状态（因为客户端试图提供的属性是不可变的，即不可修改的）。必须将Full ValueProxy实例发送到服务器，因为没有任何区别，但它将完整的属性集存储为要调用的setter列表。RequestFactory不能解决所有问题，它不是RPC的通用替代品。它往往非常适合某些问题，对其他问题几乎没有用处，而RPC几乎总是需要一些调整才能使其工作。请注意，我所说的valueproxy是entityproxy的一个属性。据我记忆所及，制作entityproxy可编辑克隆了它及其所有属性，因此valueproxy的原始未修改版本仍然存在，并且可能与其他版本有所不同。AbstractRequestContext（或者它使用的autobeans中的diff函数，我不记得很清楚）有一些逻辑，如果某个属性碰巧是valueproxy，它总是将其标记为“已编辑”。。当然，我已经有一段时间没有深入研究代码了，所以我可能是错的。。