So it is probably a good idea for the senior developer to ascertain whether some business application data is best delivered using the features of the
application level server memory (application state), as opposed to accessing the same data from the database over and over each time a web page is formulated (or once per session or once per page).
In addition to application state in ASP.NET, there
are other environmental goodies provided such as view state and session state. These are
available to both web site and web application project structures.
View state information is specific to the
web form and for the most part, travels between browser and server as hidden encrypted text within the web page content. It holds
not only information typed into text boxes but other status indications within the GUI such as drop down selections. It is automatically populated by the ASP.NET web forms framework, however the developer can add viewstate variables. View
state data or an alternative method is pretty much necessary due the nature of the web browser client, that, in its base implementation, does not remain
connected to the server (hence deemed "stateless") and thus only has an active memory space for view state when the web page is being formulated on the web server.
Session state is specific to the session and in general, not carried within the web page but stored on the server in memory (default) or on a server DB such as SQL Server (sessionState mode = "SQLServer" in web.config). Session state is formed around
a unique session ID (or method of identication for each particular user session), which is determined based on IP address, type of browser in use, start time and other facets. Pretty much every web server
has to be able to store session state info for each browser user and to be able to
re-link incoming HTTP requests with that stored session info during each round trip between client (browser or mobile) and server.
Application state information is also stored on the web server and is tied to the website boundaries as defined in IIS. It is accessible to all user sessions. We access it most typically during the formulation of certain user session web pages via the code-behind.
There are events
triggered during the website application life cycle such as Application_Start and Session_Start. Coupled with these events are various setup opportunities for the developer, essentially places for programming to be inserted that becomes tied to a previously independent action or event. Application_Start
will run the first time a page is requested subsequent to the time the web site was started. The Application and Session level start and end event programming is located in a special code file
called global.asax (and some of this is shown below).
There are concurrency considerations involved when you make a decision regarding what should be saved in application state.
In addition to the conflicts that may occur in a multi-user environment, there may also be situations where the application state info needs to be refreshed/repopulated based on changes to it outside of the website. One thing to build your thinking around first is the fact that manual changes to web.config (or even a simple update in place) by an administrater trigger a restart of the website (thus, in most cases, Application_Start). Other conditions will also trigger a restart automatically (such as exceeding an error count threshold or as a last resort, an approximately 24 time period).
Another way to trigger the re-populate of application state information is to build a
secured admin-like web page within the website. This web page could enable a way to trigger the restart or to change application state variables without requiring an admin to sign on to the web server at the OS level. In the enclosed example, like our base code product, there is a boolean indicator at the application state level indicating whether
application state is successfully populated. So resetting that to false will enable the programming to detect that application state needs to be repopulated.