是否应使用DAL访问应用程序的配置

本文关键字：应用程序 配置 访问 DAL 是否 | 更新日期: 2023-09-27 18:26:02

以下来自维基百科的定义解释了什么是多层应用程序中的数据访问层。

数据访问层（DAL）是计算机程序的一层提供对存储在的持久存储中的数据的简化访问某种，例如数据库。

持久存储也可以由一个或多个文件组成，但上层不知道我是如何组织文件中的信息的。假设我们有一个使用配置文件的应用程序，例如app.config或web.config：在app.config文件中可能有​​某些参数的值（例如缓存的最大大小），因此必须在应用程序启动期间加载这些值。此外，如果应用程序允许通过UI编辑这些参数，则应更新app.config文件。这些操作是DAL的一部分吗？

是否应使用DAL访问应用程序的配置

一点关注点的分离是明智的，因为它允许您更容易地单独测试工件，因为它们不必处理特定的关注点，例如配置存储和检索的位置和方式。

创建所需配置数据的模型并接受该模型作为依赖项（通过构造函数）可能是明智的，或者如果配置数据足够简单，它可以只是组件本身的一些属性。

在创建一个模型来传输配置信息的情况下，您将更容易在应用程序的允许用户与可配置值交互的部分中使用该对象。配置应用程序的UI本身就是一个单独的功能。

这是一个愚蠢的例子。

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)
    {
    }
}

因此，如果你使用单元测试，你可以通过给它你想要的设置来测试DAL，而不必麻烦管理你的设置的部分（下面是NUnit测试的一个无聊的例子）。

[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);
}

现在，在你的应用程序中，你可以有一个单独的组件来管理设置（如果你选择的话……也许你的设置真的很简单，这个额外的步骤是不必要的；这取决于你自己），你可以自己完全测试它。

public class SettingsManager
{
     public Settings ReadSettings(string path)
     {
         // read from the store
     }
     public void WriteSettings(Settings settings, string path)
     {
        // write settings to the store
     }
}

还有另一个无聊的测试：

[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));
}

现在在你的应用程序中，你可以做这样的事情来将它们结合在一起：

protected DAL DAL { get; private set; }
public void Init()
{
      var manager = new SettingsManager();
      DAL = new DAL(manager.ReadSettings(@"C:'settings'settings.config"));
}

走这条路的好处是现在你的DAL和你对设置的管理脱钩了。现在，您可以独立构建和测试这两个部分。让您的DAL专注于DAL内容，而设置管理器则专注于管理设置。

相关文章：