views:

49

answers:

2

Application stores configuration data in custom section of configuration file. This information is used all over the application.

Nowadays I use helper static class to to provide access like this (some code omitted or simplified):

[XmlRoot("webSiteSection")]
public class WebSiteConfig : IConfigurationSectionHandler
{

    public static WebSiteConfig Current
    {
         get
         {          
             if (_current == null)
                _current = (WebSiteConfig) ConfigurationManager.GetSection("webSiteSection");

            return _current;
     }  
    }

    [XmlElement("section1")]
    public Section1 Section1 { get; set; }

    [XmlElement("section2")]
    public Section2 Section2 { get; set; }

    ...

    public object Create(object parent, object configContext, XmlNode section)
    {
        var serializer = new XmlSerializer(typeof(WebSiteConfig));
        return serializer.Deserialize(new XmlNodeReader(section));
    }
}

Then I use it like this

<%: WebSiteConfig.Current.Section1.Value1  %>
<%: WebSiteConfig.Current.Section1.Value2  %>

What do you think of it? I find it usable because it keeps code simple, but also confused as IConfigurationSectionHandler is deprecated since .NET Framework 2.0

+1  A: 

Create your own configuration section class.

Franci Penov
Hmm, interesting :) I'll try to refactor
Andrew Florko
Well, finally i decided not to refactor as I'll have to implement so many properties. Benefits of validation are not so remarkable compared to autoproperties in approach I use these days.
Andrew Florko
That is your choice to make. However, the IConfigurationSectionHandler is deprecated as you noted yourself and might be removed in future versions of the .Net framework. I agree that worrying now about something that might break in a year might seem a bit excessive, but if you start using this pattern as implemented above quite a lot, you will end up at a state where you will have to change it eventually. Might as well do it now.
Franci Penov
+1  A: 

Well, in principal, i see nothing wrong with the concept.

A more manageable implementation may be to implement a default static instance accessor in your configuration section and use that.

Sky Sanders
Sorry, I already have static instance accessor (Current). Is that what you have mentioned?
Andrew Florko
@Andrew - so you do. I am off my game tonight missing the obvious. Ok, so Yeah, I don't see anything wrong with the way you are doing it, I do the same thing with my ConfigurationSections.
Sky Sanders
Ok. What do you think of custom configuration section classes that is suggested by Franci Penov?
Andrew Florko
@Andrew - I prefer to construct my configuration systems using the base classes as Franci says. But if your config works for you, I see nothing wrong with it. But.... There will come a time when you need to write another one and before that time comes I highly recommend that you read http://www.codeproject.com/KB/dotnet/mysteriesofconfiguration.aspx (part 1 of an amazing 3 part series). You will fall in love with the abstract configuration classes.
Sky Sanders
Andrew Florko