¿Qué convenciones / modismos / patrones está utilizando para configurar los contenedores IOC utilizando las nuevas interfaces fluidas?

Question

Estoy en medio de moverme sobre un gran cuerpo de código a Castle Trunk, que incluye la nueva interfaz fluida para configurar el contenedor. Como el proyecto tiene un enorme archivo xml windsorConfig que es más que fácil de mantener, pensé que comenzaría a aprovechar esta nueva característica. Sé que otros contenedores (por ejemplo, StructureMap 2.0) también contienen interfaces fluidas para la configuración del contenedor, por lo que esta pregunta no se basa en Windsor.

Mi pregunta es ¿qué convenciones / modismos / patrones está utilizando para la configuración de contenedores utilizando las nuevas interfaces de estilo fluido?

Mi primer pensamiento fue crear un método estático en algún lugar (por ejemplo, ContainerConfig.Config) que cargaría todos los tipos relevantes que la aplicación usa en el contenedor. Mi preocupación es que, con el tiempo, esta función monolítica terminaría siendo casi tan imposible de mantener como el archivo de configuración xml (menos el impuesto de paréntesis angular).

Mi segundo pensamiento fue desglosarlo para que cada ensamblaje dependiente, por convención, exporte su configuración predeterminada. Puedo ver que esto ha sido útil para las jerarquías utilizadas internamente por el ensamblado. Pero para los tipos que se usan externamente, ¿debería la configuración definirse internamente?

Cuanto más lo pensaba, más preguntas parecía plantear. ¿Qué piensas al respecto?

Answer 1

Eche un vistazo más profundo a StructureMap 2.5. Ofrece varias características para reducir drásticamente el trabajo de arranque del contenedor IOC. Ofrece una convención sobre la técnica de configuración (consulte las entradas del blog a continuación)

Vea las siguientes publicaciones recientes de blog de Jeremy Miller (autor de StructureMap)

Cree su propia Convención de registro automático con StructureMap

        // Example from the blog post above
        var container = new Container(registry =>
        {
            registry.Scan(x =>
            {
                x.TheCallingAssembly();
                x.With<DefaultConventionScanner>();
            });
        });

Se lanza StructureMap 2.5.2

Answer 2

Tenía un proyecto en el que estábamos usando Unity, y vi un video sobre StructureMap y me gustó la idea de registro desde el principio.

Así que creé la siguiente interfaz:

/// <summary>
/// An interface which must be implemented to create a configurator class for the UnityContainer.
/// </summary>
public interface IUnityContainerConfigurator
{
    /// <summary>
    /// This method will be called to actually configure the container.
    /// </summary>
    /// <param name="destination">The container to configure.</param>
    void Configure(IUnityContainer destination);
}

Y los ensamblados ofrecen una clase de Configurador predeterminada. También hemos envuelto nuestro Unity IoC usando una clase estática para que podamos llamar a IoC.Resolve<T>, y acabo de agregar las siguientes funciones a ese contenedor:

    /// <summary>
    /// Configure the IoC
    /// </summary>
    public static class Configure
    {
        /// <summary>
        /// Configure the IoC using by calling the supplied configurator.
        /// </summary>
        /// <typeparam name="TConfigurator">The configurator to use</typeparam>
        public static void From<TConfigurator>() where TConfigurator : IUnityContainerConfigurator, new()
        {
            From(new TConfigurator());
        }
        /// <summary>
        /// Configure the IoC using by calling the supplied configurator.
        /// </summary>
        /// <param name="configurationInterface">The configurator instance to use</param>
        public static void From(IUnityContainerConfigurator configurationInterface)
        {
            configurationInterface.Configure(instance);
        }
        // other configuration.
    }

Entonces, en el formulario de inicialización, ya sea al programa o al sitio web, simplemente llamaría:

IoC.Configure.From<BLL.DefaultMapping>();

En el BLL hay una clase como esta:

public class DefaultMapping:IUnityContainerConfigurator
{
    public void Configure(IUnityContainer destination)
    {
        destionation.RegisterType<IRepository, SQLRepository>();
        // and more..
    }
}

El único inconveniente es que todas sus capas están acopladas al contenedor de IoC elegido.

Actualización : desde esta respuesta, he publicado un artículo en mi blog que contiene el Contenedor de unidad .

Answer 3

Preguntas difíciles [y no soy un experto en IoC] pero tenga en cuenta que cualquier " función estática monolítica " no debería ser casi tan aterrador como el archivo de configuración. Puede definir sus propias convenciones para las cosas e intentar resumirlas. Uso Ninject, pero para Windsor, me imagino que implicaría hacer pequeñas funciones cortas usando cosas como Registrarse con la estrategia AllTypesOf:

kernel.Register(AllTypesOf<ISomethingProvider>.
    FromAssembly(Assembly.Load("SomeAssembly")));

No sé acerca de las jerarquías internas que exportan su propia configuración predeterminada. Eso parece un poco aterrador e invertido.

Answer 4

Podría intentar examinar el marco de Ninject. Interfaz muy simple, fluida y ultrarrápida;) Sin configuración XML y la API es bastante simple. Muy recomendable

Ninject