.config a trucos de constructor?

Question

Estoy trabajando en un proyecto rápido para monitorear/procesar datos. Básicamente, eso son solo monitores, horarios y procesadores. El monitor comprueba los datos (ftp, local, imap, pop, etc.) usando un programa y envía datos nuevos a un procesador. Todos ellos tienen interfaces.

Estoy tratando de encontrar una manera sensata de usar config para configurar qué programa/procesador utiliza cada monitor. Eso es bastante fácil:

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

Lo que estoy luchando con es ¿cuál es la mejor manera de configurar cualquier monitor antiguo/horario/procesador arrojados a la mezcla. Por un lado, se podría aplicar params constructor o propiedades (hacerle OT tomar cualquier sintaxis):

<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> 

Otra solución es el método de fábrica en cada interfaz que toma la configuración personalizada como una param:

public IMonitor Create(CustomConfigSection config); 

He visto personas usar ambos. ¿Qué prefieres? ¿Algún truco del oficio al mapear config a los constructores?

Estoy un poco desgarrado en cuanto a si DI puede encajar en este lío. Al final, sería un conjunto de enlaces por instancia de monitor, lo que parece inútil a excepción de los valores predeterminados, que config podría cubrir.

Answer 1

Cuando he hecho este tipo de cosas, he implementado un IConfigurationSectionHandler que básicamente funciona como una fábrica para analizar la configuración, crear objetos de los tipos especificados en la configuración y devolverlos en algún tipo de estructura de datos (típicamente una lista o diccionario). Ya sea que use un IConfigurationSectionHandler o no, creo que la fábrica es el camino a seguir, ya que localizará el código que trata de analizar el archivo de configuración y crear los objetos en una clase (o uno por sección).

También prefiero las clases con constructores simples y setter/getters de propiedades para la configuración de clases con muchos parámetros en el constructor. Esto hace que sea más fácil para la fábrica operar y disminuye el acoplamiento entre la fábrica y la clase que se está construyendo.

Answer 2

primer lugar, me definir elementos de configuración que representan los monitores:

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

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

y una sección de configuración de acoger ellos:

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

Entonces, me gustaría definir una interfaz que representa el conjunto de monitores:

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

Y cree una implementación que lea la configuración fil e:

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... 
      } 
     } 
    } 
} 

Esto define dónde convertir la configuración en instancias reales, que fue solo la mitad de su pregunta. Creo que la sintaxis XML que tiene para establecer las propiedades y los argumentos del constructor está bien. Es posible que pueda obtener algunas ideas de API e implementación desde Autofac's XML configuration system.

Realmente, lo que estás haciendo es un forte de contenedores de IoC; podrías buscar aprovechar uno de esos.