Follow @PDSAInc Wrap it up! - Paul Sheriff's Blog for the Real World

Paul Sheriff's Blog for the Real World

This blog is to share my tips and tricks garnered over 25+ years in the IT industry

Paul's Favorites

Wrap it up!

In our daily programming with .NET, we often find new things to use. In some cases Microsoft tells us there is something new to use. Take the case of moving from .NET 1.1 to .NET 2.0. Remember in .NET 1.1 how you used the ConfigurationSettings.AppSettings("MyValue")  to retrieve values from your .Config files? Then when .NET 2.0 came out and you attempted to upgrade your project, now all those lines of code were marked as Obsolete and a bunch of warnings were generated in your project.

Change is inevitable in this industry, and in life! However, somethings like this we can avoid with a little careful planning. I am sure most of you have discovered the benefits of using a Data Layer. This is where you create a class to wrap up ADO.NET so you spend less time writing the same ADO.NET code over and over again. The same technique should be used with configuration settings as well.

In .NET 2.0 Microsoft wants you to now use the ConfigurationManager class now to retrieve application settings and connection strings. But should you? I say NO! Once you start writing this code all over the place you have locked yourself into that way of doing things. This means that using the ConfigurationManager class you have just locked yourself into only placing your configuration settings into a Config file.

What would happen if someone needed you to store all your settings in the registry, or in an XML file on another server, or in a database table? You would have to find all those places where you used the ConfigurationManager class and replace that code. It would be better if you wrap up the ConfigurationManager class into your own class and just have methods to retrieve your various settings. Keep it simple, something like the following:

 Public Class AppConfig
  Public Shared Function ConnectString() As String
    Return System.Configuration.ConfigurationManager.ConnectionStrings("SQL").ConnectionString
  End Function

  Public Shared Function DefaultStateCode() As String
    Return System.Configuration.ConfigurationManager.AppSettings("DefaultStateCode")
  End Function
End Class

You would then use this class whenever you wished to retrieve these values, for example:

lblState.Text = AppConfig.DefaultStateCode

If you then need to change the location of where the StateCode is retrieved from, you only need to change the Shared Function DefaultStateCode to retrieve the value from the registry, a database table, or whereever.

So as you are programming your applications, think about wrapping up code that could potentially change in the future.

Have fun in your coding,

Paul

 

<a href="http://www.codeproject.com/script/Articles/BlogFeedList.aspx?amid=2032491" style="display:none" rel="tag">CodeProject</a>

Posted: Jan 12 2007, 05:00 PM by psheriff | with 4 comment(s)
Filed under: ,

Comments

John Walker said:

Paul,

I definitely like this approach and it's what I do for the most part. I think I have one improvement to it. I used shared properties as such...

Private Shared _connString as String

Private Shared ReadOnly Property ConnString() as String

If _connString Is Nothing Then

 _connString = _

System.Configuration.ConfigurationManager.ConnectionStrings("SQL").ConnectionString

End If

Return _connString

End Property

My reason for doing this is so that the class only reads from the web.config file the first time the property is accessed. After that, it just hands back the value of the Shared local variable. My reason for this is because my understanding is that accessing the web.config file each time is slightly more expensive than accessing it from memory. I could be wrong. Anyone else have any input on this?

# January 13, 2007 12:56 AM

psheriff said:

Hi John,

Yes, your approach is sound, but there might be cases where values in your Web.Config file could change and you want your program to be able to get the new value. In that case, you would want to use my approach. However, each is valid depending on your needs.

# January 13, 2007 10:20 AM

Eric Newton said:

On the other hand, does this stuff really change that often?  Over engineering is habit I have thankfully out grown.

# January 13, 2007 2:42 PM

Wim Hollebrandse said:

Paul - a change in web.config reloads the appdomain as far as I know, resulting in the the static properties being initialized again, and so John's solution works as well.

I'm not too fond of hard coding these magic key strings in the config class though and usually use a generic config wrapper class that  gets the key name of the appsetting passed in, does some checking for null etc. and returns me a string, int or whatever.

So I can then call methods on my config helper like:

string conn = ConfigHelper.GetValueAsString("connstring");

int timeout = ConfigHelper.GetValueAsInt("timeout");

These helper functions will throw proper exceptions if the value cannot be found in the configuration file.

# January 14, 2007 8:28 AM