Доступ к конфигурации приложения осуществляется с помощью DAL? - PullRequest
1 голос
/ 28 февраля 2012

Следующее определение из википедии объясняет, что такое Уровень доступа к данным в многослойном приложении.

Уровень доступа к данным (DAL)это уровень компьютерной программы, который обеспечивает упрощенный доступ к данным, хранящимся в каком-либо постоянном хранилище, таком как база данных.

Постоянное хранилище также может состоять из одного или нескольких файлов, но верхнееСлои не знают, как я организовал информацию в файлах.Предположим, у нас есть приложение, которое использует файл конфигурации, такой как app.config или web.config: в файле app.config могут быть значения некоторых параметров (например, максимальный размер кэша), поэтому онизначения должны быть загружены во время запуска приложения.Кроме того, если приложение позволяет редактировать эти параметры через пользовательский интерфейс, файл app.config должен быть обновлен.Являются ли эти операции частью DAL ?

1 Ответ

2 голосов
/ 28 февраля 2012

Небольшое разделение интересов является разумным, так как оно позволяет вам легче тестировать образцы по отдельности, поскольку они не обременены решением конкретных проблем, таких как, где и как конфигурация хранится и восстанавливается.

Это можетразумно создать модель данных конфигурации, которые вам нужны, и принять эту модель как зависимость (через конструктор), или, если данные конфигурации достаточно просты, это могут быть только некоторые свойства самого компонента.

В случае создания модели для передачи информации о конфигурации вам будет проще использовать этот объект в той части вашего приложения, которая позволяет пользователю взаимодействовать с настраиваемыми значениями.Пользовательский интерфейс для настройки вашего приложения - это отдельная функция.

Вот глупый пример.

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, а менеджер настроек - на управлении настройками.

...