Instantiating class that contains methods to check some of the settings and also return values from my app.config file

Question

I am writing a console application and have a class called ApplicationConfiguration that contains methods to check some of the settings and also return values from my app.config file. For instance the following method in the ApplicationConfiguration class returns the location of log file from my app.config file:

public string ProjectLog
        {
            get
            {
                _projectLog = ConfigurationManager.AppSettings["ProjectLog"].ToString();
                return _projectLog;
            }
        }

I have a FileLogger class and DBConnection class that also would need values returned from methods in ApplicationConfiguration. My question is since the values in the app.config file are used in many of my other classes do I have to instantiate ApplicationConfiguration in every class that may need my config values like so?

public class FileLogger
  {
        ApplicationConfiguration appConfig = new ApplicationConfiguration();
   }
public class DBConnection
  {
        ApplicationConfiguration appConfig = new ApplicationConfiguration();
  }

Answer 1

Only your program should know that appsettings exists. read it out and pass it in to your other objects. Easy

    public class Program
    {
        static void Main(string[] args)
        {
            var projectLog = ConfigurationManager.AppSettings["ProjectLog"];  
            FileLogger logger = new FileLogger(projectLog);      
            DbConnection dbConn = new DbConnection(projectLog);
            //etc etc
        }
    }

  public class FileLogger
  {
        private string logLocation;
        public FileLogger(string logLocation)
        {
            this.logLocation = loglocation;
        }
   }

Answer 2

If you are sure that your configuration setting stuff is not likely to change much, then you can wrap your configuration class in the sometimes-maligned "static" modifier like so:

namespace ConsoleAppName
{
    class Program
    {
        static void Main(string[] args)
        {
            var _projectLog = MyAppConfiguration.LogLocation;
        }
    }

    public static class MyAppConfiguration
    {
        public static string LogLocation
        {
            get { return ConfigurationManager.AppSettings["ProjectLog"]; }
        }
    }
}

Doing it this way "locks" you into having just one way of returning these settings, but if you are reasonibly sure you won't need to conditionally load different settings from the console's config based on runtime conditions, then its perfectly reasonable and clear to do it this way. Regardless, this method will give you the room to do things later like pull that setting from a database and cache it, if such a requirement arises.

Answer 3

This seems like a good use case for the singleton pattern.

Basically, it allows you to have a single class that is created once throughout the lifetime of the system, that gets created when it is accessed.

Here's a simple example:

public sealed class Configuration
{
    private static Configuration instance = null;
    private static readonly object padlock = new object();

    private string _logLocation;
    public string LogLocation { get { return _logLocation; } }

    Configuration()
    {
        _logLocation = ConfigurationManager.AppSettings["ProjectLog"];
    }

    public static Configuration Instance
    {
        get
        {
            lock (padlock)
            {
                if (instance == null)
                {
                    instance = new Singleton();
                }
                return instance;
            }
        }
    }
}

Then call it anywhere like this:

Configuration.Instance.LogLocation

While I generally agree with the general consensus that singletons are an antipattern, I've used a slightly modified version of this pattern to great success with some configuration type data.

As always, YMMV.