Небольшое разделение интересов является разумным, так как оно позволяет вам легче тестировать образцы по отдельности, поскольку они не обременены решением конкретных проблем, таких как, где и как конфигурация хранится и восстанавливается.
Это можетразумно создать модель данных конфигурации, которые вам нужны, и принять эту модель как зависимость (через конструктор), или, если данные конфигурации достаточно просты, это могут быть только некоторые свойства самого компонента.
В случае создания модели для передачи информации о конфигурации вам будет проще использовать этот объект в той части вашего приложения, которая позволяет пользователю взаимодействовать с настраиваемыми значениями.Пользовательский интерфейс для настройки вашего приложения - это отдельная функция.
Вот глупый пример.
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, а менеджер настроек - на управлении настройками.