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.