ViewState alternatives in ASP.NET Webforms

Question

Are there any other ViewState alternatives? I've heard a lot Like Session, holding the state of some of the page's controls' state and getting destroyed the moment the user leaves the page.

I know I'm describing ViewState itself, but I'm looking for a pattern of sorts or suggestions so I can avoid ViewState altogether.

An example of how I'm using it is where I'm storing the contents of my grid (A list of ViewModels) to ViewState. This helps to know which entries are dirty, which ones have been modified, their indexes, the currently selected objects, etc.

Answer 1

You have Session, and you have Cache.

Session is per user, Cache is global.

Do you really need to store all this in ViewState? why can you on submit (but you're very vague in your question so i'm making a few assumptions here) get all the old data from the DB, compare it with your new data, and update what is changed?

Answer 2

One of my colleagues has developed a way to store viewstate data in a file. So that, heavy viewstate data are not transmitted between client and server. Just a key (which is the viewstate data file) that represents the viewstate data file is held as a session variable. In our tests, we've found that saving viewstate in file decreased the server response time by decreasing the amount of viewstate (which was very huge then).

In this article under "Keeping View State on the Server", you can find out how that method can be implemented. You can even store viewstate data in a database table, which gives extra flexibilty if your application is on a web farm.

Answer 3

Another option is compressing your ViewState. It still adds bulk to the round trip, but generally it's minimal.

If you're using .Net 4, there are some useful new ViewState additions:

http://weblogs.asp.net/despos/archive/2009/06/13/asp-net-4-0-more-control-on-viewstate-management.aspx

Answer 4

I don't think you are making a case to move away from ViewState.

If you are holding a large amount of data, you'll face issues when persisting it anywhere else. Session? it'll blow your memory consumption, or if its out of process you'll be moving all of that around each time the Session is loaded/written (once per request). You can of course, try to limit the issue by freeing the stored data as soon as possible / like TempData in asp.net MVC.

You can minimize the amount of info you need to store to check for modified records by introducing a timestamp / or record version. This way you can just check if a new version has been added, and show the user both what they tried to save and what someone else saved.