以下定义from wikipedia 解释了什么是多层应用程序中的数据访问层。
数据访问层 (DAL) 是计算机程序的一层，它 提供对存储在持久存储中的数据的简化访问 某种类型，例如数据库。
持久化存储也可以包含一个或多个文件，但上层不知道我是如何组织文件中的信息的。假设我们有一个应用程序使用了一个配置文件，比如app.config或者web.config：在app.config文件中可能会有一些参数的值（比如一个缓存的最大大小），所以这些必须在应用程序启动期间加载值。此外，如果应用程序允许通过 UI 编辑这些参数，则应更新 app.config 文件。这些操作是 DAL 的一部分吗？
【问题讨论】：
标签： c# .net multi-tier
关注点的一点分离是明智的，因为它使您可以更轻松地单独测试各个部分，因为它们无需处理特定的关注点，例如存储和检索配置的位置和方式。
创建您需要的配置数据的模型并接受此模型作为依赖项（通过构造函数）可能是明智的，或者如果配置数据足够简单，它可以只是组件本身的一些属性.
在创建模型来传输配置信息的情况下，您可以更轻松地在应用程序的部分中使用该对象，该部分允许用户与可配置值进行交互。用于配置应用的 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 内容，让设置管理器专注于管理设置。
【讨论】：