.config для конструкторских трюков?

Question

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

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

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

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

<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

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

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

Answer 2

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

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

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

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 и реализации от Autofac's XML configuration system.

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