GWT请求工厂：请帮助解释完整的端到端写操作。删除方案？

最近查看了很多gwt请求工厂示例，但仍然无法找到完整的图片：

GWT请求工厂的最佳点是CRUD（创建/读取/更新/删除）。尽管如此：

即使在“更新”案例中，我也不清楚谁负责触发EntityProxyChange（事件）

我在某个地方读到（忘记在哪里），客户端请求工厂保存了一个它已经“看到”的EntityProxy本地缓存，如果它“看到”了一个新的EntityProxy缓存，那么它就会触发EntityProxy更改（事件）

这是否意味着，如果我的“updatePerson（）”方法返回一个（新更新的）PersonProxy，那么本地客户端是否会请求工厂基础结构“看到”这个新更新的person（即，通过其更新的versionId），然后是否会自动触发EntityProxyChange（事件）

在“delete”的情况下，假设我在请求上下文中创建了一个名为“deletePerson（）”的函数，我了解请求是如何到达服务器的，人们可能会这样做，例如，使用SQL delete来删除实体，但是，谁负责触发EntityProxyChange（事件）w/WriteOperation=delete？这些事件是否在服务器端触发？客户端

我已经看过listwidget示例（），但是，在“itemlist”删除中，它只是通过对整个列表进行强制刷新来“欺骗”（尽管我确实理解listwidget最初并不一定要说明这个细节）；我希望看到EntityProxyChange（事件）处理程序侦听WriteOperation.DELETE事件，然后仅从ListDataProvider中删除该实体

ServiceLayer/ServiceLayerDecorator.isLive（）是否考虑了这些因素？

请参阅

客户端不保留缓存（虽然在一年前的早期迭代中可能是这种情况，但在非里程碑版本中从未如此），服务器端负责“触发”事件（您将在JSON响应负载中看到它们）

当上面引用的wiki页面显示：

无法再检索的实体

---

它真正的意思是，

isLive

返回了

false

，

isLive

的实现默认为通过ID执行

get

，并检查非空结果。

啊，我想答案确实涉及.isLive（）。。。isLive最终调用“定位器”（这都是服务器端的），如果它返回nil，则返回WriteOperation.DELETE（从SimpleRequestProcessor获取），所有这些对于终端应用程序开发人员来说都“不感兴趣”；也就是说，他们所需要做的就是编写正确的四种“特殊”实体定位器方法Hanks Thomas；我的附加注释和