Question

The following definition from wikipedia explains what is the Data Access Layer in a multi-layered application.

A data access layer (DAL) is a layer of a computer program which
provides simplified access to data stored in persistent storage of
some kind, such as a database.

The persistent storage could also consist of one or more files, but the upper layers do not know how I organized the information in the files. Suppose we have an application that uses a configuration file, such as app.config or web.config: in the app.config file there may be the values ​​of some parameters (for example the maximum size of a cache), so these values must be loaded during application startup. Moreover, if the application allows the editing of these parameters through a UI, then the app.config file should be updated. Are these operation part of the DAL?

Answer 1

A bit of separation of concerns is sensible, as it allows you to test pieces individually easier since they are not burdened with dealing with specific concerns such as where and how configuration is stored and retrieved.

It may be sensible to create a model of the configuration data you need and accept this model as a dependency (via a constructor), or if the configuration data is simple enough, it can just be a few properties on the component itself.

In the case of creating a model to transmit configuration information, you’ll have an easier time using that object in the part of your application that allows the user to interact with configurable values. UI to configure your app is a separate feature in itself.

Here’s a silly example.

public class Settings
{
    public string SettingOne { get; set; }

    public bool SettingTwo { get; set; }

}

public class DAL
{
    public Settings Settings { get; private set; }

    public DAL(Settings settings)
    {

    }
}

So, if you use unit tests, you can test just the DAL by giving it the settings you want, without bothering with the piece that manages your settings (below is a frivolous example of an NUnit test).

[Test]
public void Should_do_something_important()
{
    // Arrange
    var dal = new DAL(new Settings { SettingOne = "whatever", SettingTwo = true });

    // Act
    var result = dal.DoSomethingImportant();

    // Assert
    Assert.That(result, Is.Not.Null);
}

Now, in your application, you can have a separate component that manages settings (if you so choose… maybe your settings are really quite simple, and this extra step is unnecessary; it’s up to you), which you can fully test on its own.

public class SettingsManager
{
     public Settings ReadSettings(string path)
     {
         // read from the store

     }

     public void WriteSettings(Settings settings, string path)
     {
        // write settings to the store
     }

}

And another frivolous test:

[Test]
public void Should_write_settings_to_store()
{
    // Arrange
    var manager = new SettingsManager();

    // Act
    var settings = new Settings { SettingOne = "value", SettingsTwo = true };
    manager.WriteSettings(settings, @"C:\settings\settings.config");

    // Assert
    Assert.That(File.Exists(@"C:\settings\settings.config", Is.True));
}

Now in your application, you can do something like this to bring them together:

protected DAL DAL { get; private set; }

public void Init()
{
      var manager = new SettingsManager();

      DAL = new DAL(manager.ReadSettings(@"C:\settings\settings.config"));
}

The benefit with going this route is now your DAL and your management of settings are uncoupled. You can now build and test the two pieces independently. Let your DAL focus on DAL stuff, and settings manager focus on managing settings.