Elegant way to implement manipulating temporary storage - ASP.NET

Question

I have a user control, on load of which I have some data from the database. A user can manipulate the data in different ways (CRUD). The process of manipulating data can cause server side events or at the client side. Then there is a save button on the page that eventually processes the temporary data and writes it to the database.

I am looking for an elegant approach to this. My thinking is:

• On load, use a hidden variable and serialize data (at that point in a form of a custom datastructure) to JSON
• On any event (server side/client side) that manipulates the data, deserialize, perform the operation and serialze back to hidden variable
• On the final save, deserialize to the datastructure that it was first loaded as and hit the database

Since all this is happening in the ASCX.CS, I can't really use the cool OOP stuff (for polymorphism if in future they decide that these operations should not be done in temp storage but rather to the database)

I am pretty much stuck with an approach of a class having a bunch of static methods that has one method for each of these operations. In the code behind, I will have to serialize/deserialze data as and when there are events that need to be handled.

EDIT-Any help?

Answer 1

ADO.Net. In memory data structure, that you would only have to commit at the end of the process.

Answer 2

The easiest way to do this is probably by storing the object in the viewstate when the page loads the first time, having the user manipulate that, and then saving it back to the database when the user wants to save it.

However, one of the problems with this approach is that if multiple users edit the same item at the same time, you could end up with a situation where data is overwritten.

Eg.

1) User A loads page and starts making changes 2) User B loads page and starts making changes 3) User A presses save. Changes are saved to database 4) User B presses save. Changes are saved to database, overwriting User A's changes.

You could get around this by using a timestamp to save the date and time of the last update, and comparing it to the one in the viewstate before committing the udpate. Alternatively, you could lock the item when someone begins editing it, stopping two people from making changes at the same time, though this solution is probably less reliable (eg. what happens if the user browses away from the page while editing).