Contents tagged with OOP

  • 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,



    <a href="" style="display:none" rel="tag">CodeProject</a>