Global Application settings and the web.config file.
While getting started on .NETOOP, one of the first issues to address is that of “Global” settings.
When you build a web application for a single purpose, you can hard-code things without much concern.
Microsoft.com is probably always going to have the same name, but .NETOOP is going to be a portal application. Everyone who uses the application will need to .NETOOP to use their own web site name (and lots of other site specific configuration data.)
Now ASP.NET has that clever “Application Settings” feature. This is a great feature that includes design time setting creating and a well factored API for reading the settings.
The problem is that these settings like “Site Name” are going to be used all over the site and the actual settings are stored in the web.config file.
Reading the .xml file several times for each page lifecycle would be VERY bad for performance.
By the way, if your worried about WRITING to the web.config file, you are right. When you save changes to a web.config file the application needs to be reset, so you defiantly do not want to do much writing to the web.config file since it will kill performance and screw up session state for in session users.
In our case we are talking about global configuration settings which will be set up when the site is originally configured and will very seldom, if ever, be changed after deployment. So the write issue is a moot point for our requirements but the READ FREQUENCY is still a big issue.
As we’re building .NETOOP we really want to take advantage of ASP.NET services, but we want the application to scale VERY well.
At first I thought perhaps the right solution was to implement a new Settings Provider that uses SQL Server as described [ HERE ]
We’ll probably have to revisit the custom provider when we implement profiles but it seemed over kill for our needs and I think I’ve implemented a better solution with less work.
Innate property caching !
Given the application settings in the following web.config snippet……
<appSettings>
<add key="SiteName" value="NETOOP Site Name" />
<add key="SiteOwner" value="NETOOP Site Owner" />
</appSettings>
We need a way for the values to be accessible and not have that access degrade performance.
Now, one of the things you may be thinking is that an application object may be a great place for this kind of data.
I’ve opted NOT to use an Application scoped object because there is a certain usage scenario that is ill-served by this.
Example: The “Title” and “MetaData” of each page should be unique and dynamic, but should include the data from the Application Setting.
So, here is my solution ….
First, a static class to contain the site’s global settings.
using System;using System.Web;using System.Web.Configuration;/// <summary>/// SiteGlobalSettings is used to "cache" settings that are used globally and frequently/// and are stored in the applications settings section of the web.config file./// This was the web.config file does not have to be read from disk each time a/// "Site Wide Setting' needs to be accessed./// When changes are made to the web.config file, the appdomain will be reset so the/// static constructor will be run when the application restarts and the new values will/// be retrieved./// </summary>public static class SiteGlobalSettings{static public string MySiteName { get; set; }static public string MySiteOwner { get; set; }static SiteGlobalSettings(){MySiteName = WebConfigurationManager.AppSettings.Get("SiteName");MySiteOwner = WebConfigurationManager.AppSettings.Get("SiteOwner");}}
This means that these values will be retrieved when the application receives it’s FIRST request for a page that uses this class, the constructor is only called ONCE, which means the web.config files only needs to be accessed once, and the class’s static properties stay in memory in between page requests.
Now I can use the global settings like this……
using System;using System.Collections.Generic;using System.Linq;using System.Web;using System.Web.UI;using System.Web.UI.WebControls;public partial class _Default : System.Web.UI.MasterPage{protected void Page_Load(object sender, EventArgs e){if (null != SiteGlobalSettings.MySiteName)Page.Header.Title = SiteGlobalSettings.MySiteName;elsePage.Header.Title = "NETOOP - The .NET Object Oriented Portal";}}
Those this code is simply using the value from the web.config file as is, I could be appending some page specific data (and I will as I implement .NETOOP). I could also declare the page title as a static variable at the page level to improve performance even more.
Share your thoughts with me !!!






Thank you for submitting this cool story - Trackback from DotNetShoutout
Pingback from Global Application settings and the web.config file. : Misfit Geek
Pingback from Global Application settings and the web.config file. | I love .NET!
Pingback from Global Application settings and the web.config file. | Nexo IT - Information Technology News
Pingback from Global Application settings and the web.config file. | Nexo IT - Information Technology News
Pingback from Global Application settings and the web.config file. : Misfit Geek
Thank you for submitting this cool story - Trackback from ravipendigg
Pingback from The Technology Post for July 6th, 2009 | I love .NET!
Pingback from The Technology Post for July 6th, 2009 | Nexo IT - Information Technology News
Pingback from The Technology Post for July 6th, 2009 | rapid-DEV.net
I don’t claim to be the best developer on the planet :) but I’m always amazed at how all the “experts” come out of the woodwork to posh on other peoples code :) Several folks have commented and emailed about hey the technique I posted earlier was unnecessary