Sign In
   Developer Productivity PKGs
Enterprise Web Apps
Accounting Suite for IBM i

Taking Advantage of Application State in ASP.NET



the Essence

This technical article provides a programming example for populating application level information in an ASP.NET web application.  From an application software developer's perspective, the essential technical feats involved are:

  • determining what multi-use data will be useful and accurate for application state
  • populating and storing the most applicable type of objects into application level memory space
  • accessing the database
  • pulling from application state memory at run time to re-populate the objects or transfer the information into its most useful format
  • initially populating the UI dropdown list box controls on the web page
Why are we here?

Good reasons for reading further into this TechCrystal...

  • To learn about application state and see an example of how it can be used

  • To see syntactical nuances and an example for instancing and populating

    System.Web.UI.WebControls.ListItemCollection


  • If you are new to OO syntax, ASP.NET or Web Forms, the introductory and tutorial-like explanations

  • To see an AJAX toolkit UpdatePanel example

  • To see how a web site project using more than one programming language is structured

  • To see the ease of using READE, Read Equal to Key, in Visual RPG for .NET programming language
the Enclosed Example

Our example for populating application state gathers a list of countries, states and provinces for US and Canada.  The clsAppViewState class generally runs just once for the application per website start.  It can be triggered to run during Application_Start most easily, but alternatively during the first Session_Start or the first session that needs the data (in order to reduce overhead during website start).

Our clsAppViewState class serializes the data using supplied framework feature(s).  The individual web pages access the data and de-serialize it later as needed.  As a general practice, Tegratecs also populates static properties of a namespace based on web.config settings at Application_Start time within our TegratecsWebBaseASPNET product, but that is going to have to wait for a separate TechCrystal.


Country and State Drop Downs

(populated via info from application state memory)

AVR.NET WebSite Example 1 Project


a little more about what data should get stored at the application level

If any of the lists of interest for application state had company specific permissions or nuances involved in presentation, then the data would not be quite as good of a candidate for storing at the application state level.  This is because, at a minimum, permissions programming would need to be coupled with the data, potentially bringing into play a number of other considerations (like where the programming is to be placed most properly and whether there is a potential permissions exposure).

A Bunch More Background

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.  

the Programing Languages

In the enclosed examples are several different kinds of source code including c# and Visual RPG for .NET.

Within the extended version of the Visual Studio 2015 IDE we are using, you can also develop c# and VB.NET if you prefer for some of the programming (in addition to Visual RPG).  Our example shows a little bit of the structuring needed when doing mixed language development in a single website.  Visual RPG for .NET provides a number of features for compatibility and ease of conversion from other RPG languages.

Visual RPG for .NET is a 3rd party .NET language developed by ASNA of San Antonio, TX.  It works with the Common Language Runtime (CLR) and the .NET Frameworks as do c# and VB.NET.  This means it has access to all of the (prebuilt by Microsoft) framework object types such as stacks and queues and arrays and the System.Web.UI.Page object. 


Code locations for application level events Global.asax contains sections for code to run based on start and end events for the application level and session level.  These events are a part of the ASP.NET lifecycle.



Setting up application level memory It is usually easiest to set up memory spaces and objects at the application level within the Application_Start event area in source code file Global.asax.



Setting up
session level namespaces using  Global.asax
This is code that runs just once whenever a new session is started.  Each new session is assigned a unique session ID unless a timed-out session is reactivated without closing the browser.  In this case, Session_Start runs with the Session ID previously used.




Finishing a session
This code runs when a session times out.  All active sessions are also ended during the process of shutting down the application in a controlled manner.




Shutting down the application
This code runs when the last active session ends, also when web.config is changed and/or various other triggers including a request from IIS Manager.




class AppViewState (accesses database to populate application state) Here is the class that populates various application level memory spaces / objects (or variables to use non-OO terminology) dependent upon a database.



Specifying the UI controls
UI controls for the web page can be specified in XHTML and stored in the .aspx source file.  We are using the XHTML 1.1 Target Schema for Validation.



code-behind the web page handling the events and drop down lists
Here is the code involved with the countries and states drop down lists.  A more complete set of the page code is available on request (register and indicate your interest (at the bottom of the registration page).  Here is a link to a functioning version of the page.



Setting up usage of multiple languages in web.config
To use more than one .NET language in a web site, you must use the web site project model.  If you want to mix languages in App_Code, you need to denote a directory for each language.  Contrary to some online and book information, you do not need to store source code on the server with the web site project model, it can be published in advance to a run time only version.







        go to the home page Top of TechCrystals Articles     go to next series page Next in TechCrystals Articles     Site Map     Switch to
Mobile View

You are at the web site of Tegratecs Development Corp.  Click here to go to the home page of this site...
Offering Innovation & Providing ROI
while minimizing Islands of Automation
Our contact information:
Tegratecs Development Corp.®
1320 Tower Road
Schaumburg, IL 60173
847-397-0088
800-739-FPSS
( please contact us or register or sign-in )
© 2012-2024