Persisting complex data between postbacks in ASP.NET MVC

Question

I'm developing an ASP.NET MVC 2 application that connects to some services to do data retrieval and update. The services require that I provide the original entity along with the updated entity when updating data. This is so it can do change tracking and optimistic concurrency. The services cannot be changed.

My problem is that I need to somehow store the original entity between postbacks. In WebForms, I would have used ViewState, but from what I have read, that is out for MVC. The original values do not have to be tamper proof as the services treat them as untrusted. The entities would be (max) 1k and it is an intranet app.

The options I have come up are:

1. Session - Ruled out - Store the entity in the Session, but I don't like this idea as there are no plans to share session between
2. URL - Ruled out - Data is too big
3. HiddenField - Store the serialized entity in a hidden field, perhaps with encryption/encoding
4. HiddenVersion - The entities have a (SQL) version field on them, which I could put into a hidden field. Then on a save I get "original" entity from the services and compare the versions, doing my own optimistic concurrency.
5. Cookies - Like 3 or 4, but using a cookie instead of a hidden field

I'm leaning towards option 4, although 3 would be simpler. Are these valid options or am I going down the wrong track? Is there a better way of doing this?

Answer 1

If you do Store it in a session then you need to ensure that if you implement a web farm that the session is loaded correctly.

We have (exactly) the same question here at the moment and what we've decided to do is to implement the Repository Pattern and link it to a cookie.

Then, if this becomes an issue, we can simply slot in either a session manager, db manager or whatever and our code need not even know because of the repository pattern.

We tinkered with the idea of hidden fields but it felt too much like ViewState and we all hated it in WebForms so the idea was scrapped. But not just because we hated view state. There were issues when you pressed Ctrl F5. The contents would be cleared and then what do you do?

So at this point its a repository pattern with a cookie which may change but the implementation lends itself kindly to change.

EDIT

We also decided against hidden fields because it would be too easy to make changes to them and so you need to do some token stuff from the server to ensure it wans't tampered with.

The hidden fields just kept on adding complexity to what essentially should have been a very simple problem.

At least that was our thoughts on the matter.

Answer 2

I am not quite sure why Session is a bad idea, if the client dose not need that backup copy, keeping the whole thing in server memory sounds the best; since the rest of the candidates are all sending from server to place (temporary) in clients' browser, and then get it back whenever client does any action. Situation is, whenever client ping back, server will unpack the encoded data (either in hidden field, cookie, url etc) and would possibly place in server again! It also waste bandwidth IMO.

OK, if client need (to inspect) the backup, I would consider hidden field(set) or simply serialize the data in XML and put it somewhere in the HTML.

EDIT

I still vote for Session. If you plan to take care the server farm, consider implement a cross server session provider:

http://msdn.microsoft.com/en-us/library/ms178587%28VS.80%29.aspx

and simply store the state in database.