Storing ViewState on filesystem

Question

I am referring this article regarding Save ViewState on the File System

This is good but not ideal because it stores nothing about which page's viewstate it is. No mapping seems to be done between a page and it's viewstate file. I want to be able to use Asp.Net webforms rich programming model while also get rid of ViewState. I could store it in Session but then it's too expensive. I would rather prefer to store it on filesystem.

One approach I could think of is store Guid for page in hidden field and store the actual ViewState in filename Guid. This would work however how do I then clean up the directory which would clear out these ViewState files? This would be a pain to create automated service for such simple task and delete these files periodically.

Any thoughts/advises?

Answer 1

Have a look at MongoDB.

http://www.mongodb.org/

and this article which persists ViewState in MongoDB, a document centric DB. This will be a lot faster than Sql Server and much better than you storing it in flat files.

An article that demostrates exactly that is:

http://highoncoding.com/Articles/699_Storing_ViewState_in_MongoDb_Database.aspx

However, your original concern of deleting old files still exists. You can write a code that cleans up old ViewState documents in Session_End event

OR

if you are using OutProc or SqlServer session mode for storing Sessions, you may have to constantly keep checking for old files in LoadPageStateFromPersistedMedium and delete old files there because Session_End don't fire for those modes but I doubt you would be using Sql Server since you are so concerned about it :)

Answer 2

You can use SQL server to store session state. That would be a lot better than "rolling your own" solution.

http://support.microsoft.com/kb/317604

Answer 3

Take a look at Windows Server AppFabric. It is simple to implement via config settings...

http://msdn.microsoft.com/en-us/windowsserver/ee695849

http://en.wikipedia.org/wiki/AppFabric

Answer 4

One thing many people overlook on ViewState is that it is defaulted to enabled on all controls, and in many cases it is not needed. If I was concerned about ViewState size, the first thing I would do would be to disable ViewState whereever it is not needed.

The solution discussed in the CP article, does not mention that ViewState must be used for controls where the user can directly change the value, such as a textbox. Unless you use some JavaScript or jQuery workaround and a bunch of query strings, ViewState is the way to get back the values a user has entered on the form.

So, the only place where the solution you are considering would be of value would be a place where you have an asp:Label or asp:Literal and are changing that value in server-side code in response to a button click or some other event, and need to make sure that the change is persisted over subsequent post backs.

Answer 5

based on your question, if you don't want the HTML overload of viewstate you could disable it for all controls. Do you really need to remember the values from the textboxes?

If you want to maintain the viewstate but not in the HTML, i would recommend the session, by default it uses the server memory, its fast. You can even use Session in SQL or a windows service, slower options.

You can also use cookies if you like, that's another option and stays on the client.

I would not recommend using files, it is slow to read and only one user can access these files so you have to generate and maintain a lot of files.

But based on my experience, i would disable viewstate, or leave it without change.

Hope it helps.

Answer 6

The code that saves the ViewState can iterae the files in whatever directory you are saving ViewStates in and delete any that you consider expired. Technically this allows very old ViewState t hang around -- but only if no new ViewStates are being saved, so they won't be overflowing your filesystem.

Alternatvely, it can launch a thread to do this in the background. A flag stored in the Application context can be used to avoid launching this multiple times. I like this solution less because it's more complicated.