title: Design pattern for client server updates
body: <p>I am writing a Flex application that is using MVC on the client side. It uses GraniteDS and so has Remote Lazy Loading and Reverse Lazy Loading features.</p>
  
  <p>The user logs into the application and then clicks a button to update their email address. The controller is then called but I am not sure which order to do things in next. I can see the following options:</p>
  
  <p><strong>Options</strong></p>
  
  <ol>
  <li>Update the model on the client, and then send the update to the server. If the server throws an error then tell the user and ask them to reload the Flex application as the data is now out of phase. Otherwise assume that the update went OK;</li>
  <li>The controller sends the data to the server, after the server responds then the controller updates the client model with the updated data. If no server response is received then tell the user there has been an error and ask them to reload the application as the data may now be out of phase.</li>
  </ol>
  
  <p>Option 2 seems better but I am unsure how to implement it. What are my options?</p>
  
  <p><strong>Solutions</strong></p>
  
  <ol>
  <li>Clone the <em>MyUser</em> and send the clone to the server, when the server returns <em>MyUser</em> then update the model. How would you handle deeper nested Objects in collections of <em>MyUser</em> as a clone would only copy the original collection and not clone it?</li>
  <li>Send the <em>MyUser.id</em> to the server with the changed data. Load the <em>MyUser</em> on the server using the <em>id</em> and then modify their data. Once their data is modified on the server then return the <em>MyUser</em> to the client so that the controller can update them model.</li>
  </ol>
  
  <p>Solution 2 would seem to be a very bad way to do this as it circumvents the GraniteDS features of Lazy/Reverse Lazy loading.</p>
  
  <p>Is their a best practice way to do this?</p>