In his article, Understanding ASP.NET View State, Scott presented a section
about storing the ASP.NET view state into a persistent medium, instead of
storing it in the page itself. He used the system file system, mainly a simple
text file to store the page’s view state. However, Scott did mention a few
weaknesses in his approach and proposed some ideas on how to improve his
method.
The following is quoted from Scott Mitchell’s article.
"There are two main challenges with this approach:
1.
Coming up with an acceptable file naming scheme. Since the view state
for a page will likely vary based on the user's interactions with the page, the
stored view state must be unique for each user and for each page.
2.
Removing the view state files from the file system when they are no
longer needed."
To tackle the first challenge, we will name the persisted
view state file based on the user's SessionID and the page's URL. This
approach will work beautifully for all users whose browsers accept
session-level cookies. Those that do not accept cookies, however, will have a
unique session ID generated for them on each page visit, thereby making this
naming technique unworkable for them. For this article I am just going to
demonstrate using the SessionID / URL file name scheme, although it will not
work for those whose browsers are configured not to accept cookies. Also, it
will not work for a Web farm unless all servers store the view state files to a
centralized location.
Note: One workaround would be to use
a globally unique identifier (GUID) as the file name for the persisted view
state, saving this GUID in a hidden form field on the ASP.NET Web page. This
approach, unfortunately, would take quite a bit more effort than using the
SessionID / URL scheme, since it involves injecting a hidden form field into
the Web Form. For that reason, I will stick to illustrating the simpler
approach for this article.
The second challenge arises because each time a user visits
a different page, a new file holding that page's view state will be created. Over
time this will lead to thousands of files. Some sort of automated task would
be needed to periodically clean out the view state files older than a certain
date. I leave this as an exercise for the reader.
In this article we are going to improve the method presented
by Scott. The improvement will include the following two sections.
First, we will use a GUID to name the text file used to
store the view state. This GUID will be generated per page and stored in a
hidden field inside the page.
Second, we will be adding a semi-scheduler for deleting the
view state files based on a certain threshold that we can control by having a
key inside the Web.config.
