Design pattern for client server updates

Question

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.

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:

Options

1. 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;
2. 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.

Option 2 seems better but I am unsure how to implement it. What are my options?

Solutions

1. Clone the MyUser and send the clone to the server, when the server returns MyUser then update the model. How would you handle deeper nested Objects in collections of MyUser as a clone would only copy the original collection and not clone it?
2. Send the MyUser.id to the server with the changed data. Load the MyUser on the server using the id and then modify their data. Once their data is modified on the server then return the MyUser to the client so that the controller can update them model.

Solution 2 would seem to be a very bad way to do this as it circumvents the GraniteDS features of Lazy/Reverse Lazy loading.

Is their a best practice way to do this?

Answer 1

If you have a data conflict when saving a flex object, reloading the whole flex application is a solution that is not very handy but it works and is very reliable. For a request: maybe you should just show a message, and allowing the flex client to re-send the request (for instance: network problem) and it should be most of the time ok. Add a counter if it bothers you to restart the application after n fails (you can program a flex application to reload itself by using a URLRequest).

About cloning MyUser: if you use basic AMF serialization with ObjectUtil.copy() it will copy the nested fields as it is indeed a "deep copy" based on IExternalizable and granite serialization is based on that. So your solution about cloning objects should work.

You are free to use graniteds the way you want, for instance many people prefer disabling the lazy-features even if it brings its own problems. I feel that dealing with data conflicts is always a custom thing, don't expect a framework, even Granite, to solve all the problems.