Architecture 客户端-服务器更新的设计模式

我正在编写一个在客户端使用MVC的Flex应用程序。它使用GraniteDS，因此具有远程延迟加载和反向延迟加载功能

用户登录应用程序，然后单击按钮更新其电子邮件地址。然后调用控制器，但我不确定下一步的操作顺序。我可以看到以下选项：

选项

在客户机上更新模型，然后将更新发送到服务器。如果服务器抛出错误，那么告诉用户并要求他们重新加载Flex应用程序，因为数据现在不同步。否则，假设更新正常

控制器将数据发送到服务器，服务器响应后，控制器使用更新的数据更新客户端模型。如果没有收到服务器响应，则告诉用户出现错误，并要求他们重新加载应用程序，因为数据现在可能不同步

选项2似乎更好，但我不确定如何实施它。我有什么选择

解决方案

克隆MyUser并将克隆发送到服务器，服务器返回MyUser后更新模型。当克隆只复制原始集合而不克隆它时，如何处理MyUser集合中更深层次的嵌套对象

将MyUser.id与更改的数据一起发送到服务器。使用id在服务器上加载MyUser，然后修改其数据。一旦他们的数据在服务器上被修改，然后将MyUser返回到客户端，以便控制器可以更新他们的模型

解决方案2似乎是一种非常糟糕的方法，因为它绕过了延迟/反向延迟加载的特性

---

这是一种最佳实践方法吗？

如果您在保存flex对象时遇到数据冲突，那么重新加载整个flex应用程序是一种解决方案，虽然不是很方便，但它可以工作并且非常可靠。 对于请求：也许您应该只显示一条消息，并允许flex客户端重新发送请求（例如：网络问题），大多数情况下应该可以。如果在n失败后重新启动应用程序时遇到麻烦，请添加计数器（您可以通过使用URLRequest对flex应用程序进行编程以重新加载自身）

关于克隆MyUser：如果将基本AMF序列化与ObjectUtil.copy（）一起使用，它将复制嵌套字段，因为它确实是基于IExternalizable的“深度副本”，granite序列化就是基于此。因此，关于克隆对象的解决方案应该是可行的

您可以按照自己的方式自由使用graniteds，例如，许多人喜欢禁用lazy特性，即使它会带来自己的问题。我觉得处理数据冲突始终是一件定制的事情，不要指望一个框架，甚至Granite，来解决所有的问题