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

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
  

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.

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).

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.  

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.