¿Cómo se comparan los principales marcos C # DI / IoC? [cerrado]

A riesgo de entrar en territorio de guerra santa, ¿cuáles son las fortalezas y debilidades de estos marcos populares de DI / IoC, y podría uno ser fácilmente considerado el mejor? ..:

• Ninject
• Unidad
• Castillo Windsor
• Autofac
• EstructuraMapa

¿Hay otros marcos DI / IoC para C # que no haya enumerado aquí?

En el contexto de mi caso de uso, estoy creando una aplicación WPF de cliente y una infraestructura de servicios WCF / SQL, facilidad de uso (especialmente en términos de sintaxis clara y concisa), documentación consistente, buen soporte comunitario y rendimiento son factores importantes. En mi elección.

Actualizar:

Los recursos y las preguntas duplicadas citadas parecen estar desactualizadas. ¿Puede alguien con conocimiento de todos estos marcos presentarse y proporcionar una idea real?

Me doy cuenta de que es probable que la mayoría de las opiniones sobre este tema sea parcial, pero espero que alguien se haya tomado el tiempo de estudiar todos estos marcos y tener al menos una comparación generalmente objetiva.

Estoy bastante dispuesto a hacer mis propias investigaciones si esto no se ha hecho antes, pero asumí que esto era algo que al menos algunas personas ya habían hecho.

Segunda actualización

Si tiene experiencia con más de un contenedor DI / IoC, clasifique y resuma los pros y los contras de ellos, gracias. Este no es un ejercicio para descubrir todos los pequeños contenedores oscuros que la gente ha hecho, estoy buscando comparaciones entre los marcos populares (y activos).

Si bien una respuesta integral a esta pregunta ocupa cientos de páginas de mi libro , aquí hay una tabla de comparación rápida en la que todavía estoy trabajando:

Me encontré con otra comparación de rendimiento (última actualización 10 de abril de 2014). Compara lo siguiente:

• AutoFac
• LightCore (el sitio es alemán)
• LinFu
• Ninject
• Chiquita
• Inyector simple (el más rápido de todos los concursantes)
• Spring.NET
• EstructuraMapa
• Unidad
• Windsor
• Hiro

Aquí hay un resumen rápido de la publicación:

Conclusión

Ninject es definitivamente el contenedor más lento.

MEF, LinFu y Spring.NET son más rápidos que Ninject, pero siguen siendo bastante lentos. AutoFac, Catel y Windsor son los siguientes, seguidos de StructureMap, Unity y LightCore. Una desventaja de Spring.NET es que solo se puede configurar con XML.

SimpleInjector, Hiro, Funq, Munq y Dynamo ofrecen el mejor rendimiento, son extremadamente rápidos. ¡Pruébalos!

Especialmente el inyector simple parece ser una buena opción. Es muy rápido, tiene una buena documentación y también admite escenarios avanzados como intercepción y decoradores genéricos.

También puede intentar usar la Biblioteca de selector de servicios comunes y, con suerte, probar varias opciones y ver qué funciona mejor para usted.

Alguna información sobre la Biblioteca Selector de Servicio Común del sitio:

La biblioteca proporciona una abstracción sobre contenedores de IoC y localizadores de servicios. El uso de la biblioteca permite que una aplicación acceda indirectamente a las capacidades sin depender de referencias duras. La esperanza es que al usar esta biblioteca, las aplicaciones y los marcos de terceros puedan comenzar a aprovechar IoC / Service Location sin atarse a una implementación específica.

Actualizar

13.09.2011: Funq y Munq se agregaron a la lista de concursantes. Los gráficos también se actualizaron y Spring.NET se eliminó debido a su bajo rendimiento.

11/04/2011: "se agregó Simple Injector , el rendimiento es el mejor de todos los concursantes"

Solo lea este gran blog de comparación de contenedores .Net DI de Philip Mat.

Realiza algunas pruebas exhaustivas de comparación de rendimiento;

• Autofac
• EstructuraMapa
• Ninject
• Unidad
• Castillo Windsor
• Spring.Net

Recomienda Autofac ya que es pequeño, rápido y fácil de usar ... Estoy de acuerdo. Parece que Unity y Ninject son los más lentos en sus pruebas.

Descargo de responsabilidad: a principios de 2015, hay una gran comparación de las características de IoC Container de Jimmy Bogard , aquí hay un resumen:

Contenedores comparados:

• Autofac
• Ninject
• Inyector simple
• EstructuraMapa
• Unidad
• Windsor

El escenario es este: tengo una interfaz, IMediator, en la que puedo enviar una sola solicitud / respuesta o una notificación a múltiples destinatarios:

public interface IMediator 
{ 
    TResponse Send<TResponse>(IRequest<TResponse> request);

    Task<TResponse> SendAsync<TResponse>(IAsyncRequest<TResponse> request);

    void Publish<TNotification>(TNotification notification)
        where TNotification : INotification;

    Task PublishAsync<TNotification>(TNotification notification)
        where TNotification : IAsyncNotification; 
}

Luego creé un conjunto base de solicitudes / respuestas / notificaciones:

public class Ping : IRequest<Pong>
{
    public string Message { get; set; }
}
public class Pong
{
    public string Message { get; set; }
}
public class PingAsync : IAsyncRequest<Pong>
{
    public string Message { get; set; }
}
public class Pinged : INotification { }
public class PingedAsync : IAsyncNotification { }

Estaba interesado en ver algunas cosas con respecto al soporte de contenedores para genéricos:

• Configuración para genéricos abiertos (registrando IRequestHandler <,> fácilmente)
• Configuración para múltiples registros de genéricos abiertos (dos o más INotificationHandlers)

Configuración para la variación genérica (registro de controladores para INotification base / creación de canalizaciones de solicitud) Mis controladores son bastante sencillos, solo salen a la consola:

public class PingHandler : IRequestHandler<Ping, Pong> { /* Impl */ }
public class PingAsyncHandler : IAsyncRequestHandler<PingAsync, Pong> { /* Impl */ }

public class PingedHandler : INotificationHandler<Pinged> { /* Impl */ }
public class PingedAlsoHandler : INotificationHandler<Pinged> { /* Impl */ }
public class GenericHandler : INotificationHandler<INotification> { /* Impl */ }

public class PingedAsyncHandler : IAsyncNotificationHandler<PingedAsync> { /* Impl */ }
public class PingedAlsoAsyncHandler : IAsyncNotificationHandler<PingedAsync> { /* Impl */ }

Autofac

var builder = new ContainerBuilder();
builder.RegisterSource(new ContravariantRegistrationSource());
builder.RegisterAssemblyTypes(typeof (IMediator).Assembly).AsImplementedInterfaces();
builder.RegisterAssemblyTypes(typeof (Ping).Assembly).AsImplementedInterfaces();

• Genéricos abiertos: sí, implícitamente
• Múltiples genéricos abiertos: sí, implícitamente
• Contravarianza genérica: sí, explícitamente

Ninject

var kernel = new StandardKernel();
kernel.Components.Add<IBindingResolver, ContravariantBindingResolver>();
kernel.Bind(scan => scan.FromAssemblyContaining<IMediator>()
    .SelectAllClasses()
    .BindDefaultInterface());
kernel.Bind(scan => scan.FromAssemblyContaining<Ping>()
    .SelectAllClasses()
    .BindAllInterfaces());
kernel.Bind<TextWriter>().ToConstant(Console.Out);

• Genéricos abiertos: sí, implícitamente
• Múltiples genéricos abiertos: sí, implícitamente
• Contravarianza genérica: sí, con extensiones creadas por el usuario

Inyector simple

var container = new Container();
var assemblies = GetAssemblies().ToArray();
container.Register<IMediator, Mediator>();
container.Register(typeof(IRequestHandler<,>), assemblies);
container.Register(typeof(IAsyncRequestHandler<,>), assemblies);
container.RegisterCollection(typeof(INotificationHandler<>), assemblies);
container.RegisterCollection(typeof(IAsyncNotificationHandler<>), assemblies);

• Genéricos abiertos: sí, explícitamente
• Múltiples genéricos abiertos: sí, explícitamente
• Contravarianza genérica: sí, implícitamente (con la actualización 3.0)

EstructuraMapa

var container = new Container(cfg =>
{
    cfg.Scan(scanner =>
    {
        scanner.AssemblyContainingType<Ping>();
        scanner.AssemblyContainingType<IMediator>();
        scanner.WithDefaultConventions();
        scanner.AddAllTypesOf(typeof(IRequestHandler<,>));
        scanner.AddAllTypesOf(typeof(IAsyncRequestHandler<,>));
        scanner.AddAllTypesOf(typeof(INotificationHandler<>));
        scanner.AddAllTypesOf(typeof(IAsyncNotificationHandler<>));
    });
});

• Genéricos abiertos: sí, explícitamente
• Múltiples genéricos abiertos: sí, explícitamente
• Contravarianza genérica: sí, implícitamente

Unidad

container.RegisterTypes(AllClasses.FromAssemblies(typeof(Ping).Assembly),
   WithMappings.FromAllInterfaces,
   GetName,
   GetLifetimeManager);

/* later down */

static bool IsNotificationHandler(Type type)
{
    return type.GetInterfaces().Any(x => x.IsGenericType && (x.GetGenericTypeDefinition() == typeof(INotificationHandler<>) || x.GetGenericTypeDefinition() == typeof(IAsyncNotificationHandler<>)));
}

static LifetimeManager GetLifetimeManager(Type type)
{
    return IsNotificationHandler(type) ? new ContainerControlledLifetimeManager() : null;
}

static string GetName(Type type)
{
    return IsNotificationHandler(type) ? string.Format("HandlerFor" + type.Name) : string.Empty;
}

• Genéricos abiertos: sí, implícitamente
• Múltiples genéricos abiertos: sí, con extensión creada por el usuario
• Contravarianza genérica: derp

Windsor

var container = new WindsorContainer();
container.Register(Classes.FromAssemblyContaining<IMediator>().Pick().WithServiceAllInterfaces());
container.Register(Classes.FromAssemblyContaining<Ping>().Pick().WithServiceAllInterfaces());
container.Kernel.AddHandlersFilter(new ContravariantFilter());

• Genéricos abiertos: sí, implícitamente
• Múltiples genéricos abiertos: sí, implícitamente
• Contravarianza genérica: sí, con extensión creada por el usuario

En realidad, hay toneladas de marcos IoC. Parece que cada programador intenta escribir uno en algún momento de su carrera. Quizás no para publicarlo, sino para aprender el funcionamiento interno.

Personalmente prefiero autofac ya que es bastante flexible y tiene una sintaxis que me conviene (aunque realmente odio que todos los métodos de registro sean métodos de extensión).

Algunos otros marcos:

• https://simpleinjector.org/
• http://microioc.codeplex.com/
• http://munq.codeplex.com/
• http://funq.codeplex.com/

Bueno, después de buscar la mejor comparación que he encontrado hasta ahora es:

• http://www.sturmnet.org/blog/2010/03/04/poll-ioc-containers-for-net

• http://www.sturmnet.org/blog/2010/03/04/poll-results-ioc-containers-for-net

Fue una encuesta realizada en marzo de 2010.

Un punto de interés para mí es que las personas que han usado un Marco DI / IoC y les ha gustado / no les ha gustado, StructureMap parece estar en la cima.

También de la encuesta, parece que Castle.Windsor y StructureMap parecen ser los más favorecidos.

Curiosamente, Unity y Spring.Net parecen ser las opciones populares que generalmente no están de acuerdo. (Estaba considerando Unity por pereza (y soporte / insignia de Microsoft), pero ahora estaré mirando más de cerca a Castle Windsor y StructureMap).

Por supuesto, esto probablemente (?) No se aplica a Unity 2.0, que se lanzó en mayo de 2010.

Esperemos que alguien más pueda proporcionar una comparación basada en la experiencia directa.

Consulte para una comparación de net-ioc-frameworks en el código de google, incluidos linfu y spring.net que no están en su lista mientras escribo este texto.

Trabajé con spring.net: tiene muchas características (aop, bibliotecas, documentos, ...) y hay mucha experiencia en dotnet y el mundo java. Las características están modularizadas para que no tenga que tomar todas las características. Las características son abstracciones de problemas comunes como la extracción de bases de datos, la extracción de registros. sin embargo, es difícil hacer y depurar la configuración de IoC.

Por lo que he leído hasta ahora: si tuviera que elegirh para un proyecto pequeño o mediano, usaría ninject ya que la configuración ioc está hecha y se puede depurar en c #. Pero todavía no he trabajado con eso. para un sistema modular grande, me quedaría con spring.net debido a las bibliotecas de abstracción.