.config к хитростям конструктора?

Question

Я работаю над быстрым проектом по мониторингу / обработке данных. По сути, это просто мониторы, графики и процессоры. Монитор проверяет данные (ftp, local, imap, pop и т. Д.) По расписанию и отправляет новые данные в процессор. Все они имеют интерфейсы.

Я пытаюсь найти разумный способ использовать config для настройки расписания / процессора, используемого каждым монитором. Это довольно просто:

<monitor type="any.class.implementing.monitor">
    <schedule type="any.class.implementing.schedule">
        ...
    </schedule>
    <processor type="any.class.implementing.processor" />
</monitor>

То, с чем я борюсь, - это лучший способ настроить любой старый монитор / расписание / процессор, добавленный в микс. С одной стороны, можно реализовать параметры или свойства конструктора (не использовать синтаксис):

<monitor type="any.class.implementing.monitor">
    <args>
        <arg value="..." />
    </args>
    <properties>
        <property name="..." value=..." />
    </properties>
    <schedule type="any.class.implementing.schedule">
        ...
    </schedule>
    <processor type="any.class.implementing.processor" />
</monitor>

Другим решением является заводской метод в каждом интерфейсе, который принимает пользовательскую конфигурацию в качестве параметра:

public IMonitor Create(CustomConfigSection config);

Я видел, как люди используют оба. Что Вы предпочитаете? Какие уловки торговли при отображении конфигурации на конструкторы?

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

Answer 1

Сначала я бы определил элементы конфигурации, представляющие мониторы:

public class MonitorElement : ConfigurationElement
{
    // ...whatever schema you prefer...
}

public class MonitorElementCollection : ConfigurationElementCollection
{
    // ...standard implementation...
}

И раздел конфигурации для их размещения:

public class YourSection : ConfigurationSection
{
    [ConfigurationProperty("monitors")]
    [ConfigurationCollection(typeof(MonitorElementCollection))]
    public MonitorElementCollection Monitors
    {
        get { return (MonitorElementCollection) this["monitors"]; }
    }
}

Затем я бы определил интерфейс, представляющий набор мониторов:

public interface IMonitorRepository
{
    IEnumerable<Monitor> GetMonitors();
}

И создайте реализацию, которая читает файл конфигурации:

public sealed class ConfiguredMonitorRepository : IMonitorRepository
{
    private readonly string _sectionName;

    public ConfiguredMonitorRepository(string sectionName)
    {
        _sectionName = sectionName;
    }

    public IEnumerable<Monitor> GetMonitors()
    {
        var section = (YourSection) ConfigurationManager.GetSection(_sectionName);

        if(section != null)
        {
            foreach(var monitor in section.Monitors)
            {
                yield return ...create and configure monitor...
            }
        }
    }
}

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

На самом деле то, что вы делаете, это сильная сторона IoC-контейнеров; Вы могли бы использовать один из них.

Answer 2

Когда я сделал это, я реализовал IConfigurationSectionHandler, который в основном работает как фабрика для анализа конфигурации, создания объектов типов, указанных в конфигурации, и возврата их в какие-то данные. структура (обычно список или словарь). Используете ли вы IConfigurationSectionHandler или нет, я думаю, что фабрика - это путь, поскольку вы локализуете код, который занимается синтаксическим анализом файла конфигурации и созданием объектов в одном классе (или по одному на раздел).

Я также предпочитаю классы с простыми конструкторами и установщиками / получателями свойств для конфигурации, а не классы с большим количеством параметров в конструкторе. Это облегчает работу фабрики и уменьшает связь между фабрикой и классом, который строится.