Keeping configuration data external from Class Libraries

Question

Say I have an application with the following structure.

// ASP.NET MVC (Web Project)
// Service/Business Layer (Class Library)
// DAL (Class Library)

Initially I wanted to use an App.config file in the DAL class library which would hold app settings like this:

<appSettings>
   <add key="DAL-Assembly" value="DAL.LinqToSql.DataContexts"/>
   <add key="DAL-Type" value="DAL.LinqToSql.DataContexts.MyDataContext" />
</appSettings>

And then I would use a factory to create the data context using reflection

public static DataContext GetContext()
{
    string assembly = ConfigurationManager.AppSettings("DAL-Assembly");
    string type = ConfigurationManager.AppSettings("DAL-Type");

    Assembly a = Assembly.Load(assembly);
    return (DataContext)a.CreateInstance(type);
}

The problem is that now I understand that a Class Library has to use the configuration file of the calling application. Which means that it would be looking in the presentation for the app.config or web.config - which doesn't seem right.

In this DAL situation, what is the best way to keep the concrete DataContext specification contained in the DAL layer, without having to rebuild each time it is changed? Or even in a broader sense, the best way to keep configuration external in the DAL layer?

Sorry, but this is how .NET has done it since Day 1. It also makes sense, since the configuration is with the _application_. Don't think of it as "the presentation layer". The web site _is_ the application. — John Saunders, Oct 12 '11 at 04:50

score 3 · Accepted Answer · edited May 23 '17 at 11:47

I would try and keep the configuration separate and actually inject it into the layer in question. So in your DAL layer I would perhaps have a factory class that dealt out the particular data gateways and this factory would take an IDataAccessConfiguration parameter in its default constructor. Then you could set static properties in a local configuration class or pass a local copy of the interface into a context when creating it. Example :

public interface IDataAccessConfiguration
{
    string Assembly { get; }
    string Type { get; }
}

public sealed class DataAccessfactory
{
    private IDataAccessConfiguration Config { get; set; }

    public DataAccessfactory(IDataAccessConfiguration config)
    {
        this.Config = config;
    }

    public ISomeDataContext GetSomeDataContext()
    {
        return new SomeDataContext(this.Config);
    }
}

public class SomeDataContext : ISomeDataContext
{
    private IDataAccessConfiguration Config { get; set;}

    public SomeDataContext(IDataAccessConfiguration config)
    {
        this.Config = config;
    }

    private DataContext GetDataContext()
    {
        Assembly a = Assembly.Load(this.Config.Assembly);       
        return (DataContext)a.CreateInstance(this.Config.Type);  
    }
}

Then, when you actually want to get the settings from the particular app.config file you can do it in the standard manner, create a concrete class that implements IDataAccessConfiguration and set its members with the values from the config file and pass that class around. See this link for a question I asked that relates to this : Best way of injecting application configuration

Is this the sort of thing you are looking for?

score 0 · Answer 2 · answered Oct 12 '11 at 05:55

I always create a Config class with static readonly properties for all the values read from .config files. It's tremendously helpful, as it gives you easy access to the strongly types values and it doesn't really if the value is set in a web.config for your website, or in a app.config for your test projects.

public class Config
{
    public static string QueriesPath
    {
        get
        {
            return ConfigurationManager.AppSettings["QueriesPath"].ToString();
        }
    }

    public static string SearchLogConnectionString
    {
        get
        {
            return ConfigurationManager.ConnectionStrings["SearchLog"].ConnectionString;
        }
    }
}

I always keep a Config class like that with the project that depends on the settings. In your scenario, the DAL and Service layer will probably each have such a class. I also do basic forms of validation, i.e. check for missing values and throw appropiate exceptions so the app fails as fast as possible, or just return a sensible default value.

Be careful to name your configuration values uniquely, I usually prefix them with the project name, if I know the library is going to be used in other scenarios.

Whilst not a bad approach, you are also tying your application / layers to a concrete style of configuration. What happens if you say want to use a database to get your config? Now you have to change all your config classes as they are defaulted to using the Configuration Manager. If everything is hidden behind an interface, then only the top level that obtains the configuration has to change, which if you are using an IoC strategy, is pretty straight forward. — Bertie, Apr 04 '12 at 09:24
Where I should place Config class? At DataLayer project, at Business project .. ? — emert117, Sep 04 '19 at 14:30
@emert117 each project can/should have a Config class to access the settings it defines. — Jakob Gade, Sep 05 '19 at 12:54

Keeping configuration data external from Class Libraries

2 Answers2