¿Por qué uno utilizaría un contenedor DI de terceros sobre el contenedor integrado de DI de ASP.NET?

Como actualmente hay una falta de documentación sobre el tema DI – Dependency Injection . ¿Alguien puede ayudarme a comprender lo siguiente?

  1. ¿Cuál es la diferencia entre estos registros?

    public void ConfigureServices(IServiceCollection services) { services.AddTransient(); services.AddScoped(); services.AddSingleton(); services.AddInstance(service); } 
  2. ¿Cuáles son las ventajas y desventajas de usar DI integrado en soluciones existentes como (NInject, Autofac, Structure Map)?
  3. ¿Cuáles son las limitaciones actuales de la dependency injection predeterminada (si corresponde)?

Para el desarrollo de productos de cualquier aplicación de tamaño considerable que siga los principios SOLID, el contenedor DI incorporado de vNext será inútil, porque:

  • No lo ayuda a verificar su configuración, por lo que es muy difícil diagnosticar problemas que provienen de configuraciones erróneas comunes. En una aplicación de tamaño razonable, en realidad es bastante difícil detectar estos errores usted mismo.
  • Es imposible aplicar preocupaciones transversales usando interceptores o decoradores de una manera sostenible. Esto hace que el mantenimiento de cualquier aplicación de un tamaño razonable sea realmente costoso.
  • Aunque admite el mapeo de abstracciones genéricas abiertas para abrir implementaciones genéricas, su implementación es bastante ingenua y no puede trabajar con tipos generics con restricciones de tipo y mapeos de tipos generics más complejos.
  • Es imposible realizar registros condicionales, de tal manera que los registros solo se inyectan a un determinado grupo de consumidores.

Si comienzas con un proyecto nuevo y simple, mi consejo es aplicar Pure DI (que significa componentes con cable a mano sin el uso de un contenedor) y resolver tus tipos conectando tu IControllerActivator personalizado . Más adelante, cuando funciones como el registro por lotes y la decoración mejoren la capacidad de mantenimiento de Composition Root , cambie a una de las bibliotecas DI establecidas que se adapte a sus necesidades.

Aquí se explica:

  • Transitorio: una nueva instancia se crea cada vez
  • Alcance: se crea una única instancia dentro del scope actual. Es equivalente a Singleton en el scope actual
  • Singleton: se crea una única instancia y actúa como un singleton
  • Instancia: se proporciona una instancia específica todo el tiempo. Usted es responsable de su creación inicial

La versión Alpha tenía estas limitaciones:

  • Solo admite la inyección de constructor
  • Solo puede resolver tipos con un solo constructor público
  • No admite funciones avanzadas (como por scope de hilo o descubrimiento automático)

Si no está escribiendo el contenedor DI por defecto del producto realmente complicado, debería ser suficiente para usted. En otros casos, puede probar las bibliotecas que ya mencionó que tienen características avanzadas.

Mi consejo sería comenzar con el predeterminado y cambiar la implementación cuando (si) tocas algo que no puedes hacer con él.

¿Cuál es la diferencia entre estos registros?

  • Transitorio: instanciado cada vez que se recupera
  • Scoped: instanciado una vez por solicitud HTTP y estará disponible durante toda la vida de la solicitud http
  • Singleton: instanciado una vez y estará disponible durante toda la vida útil de su aplicación
  • Instancia: equivalente a singleton, excepto que proporciona la instancia del objeto en lugar del marco que crea la instancia

Fuente: http://www.khalidabuhakmeh.com/asp-vnext-dependency-injection-lifecycles , http://dotnetliberty.com/index.php/2015/10/15/asp-net-5-mvc6-dependency- inyección-en-6-pasos /

Para responder a su primera pregunta: parece que los documentos de ASP.NET se actualizaron y ahora indican claramente para qué es cada tipo de registro:

Los servicios ASP.NET se pueden configurar con los siguientes tiempos de vida:

Transitorio

Los servicios de duración transitoria se crean cada vez que se solicitan. Esta vida útil funciona mejor para el servicio liviano y sin estado.

Alcance

Los servicios de por vida con scope se crean una vez por solicitud.

Semifallo

Los servicios de por vida de Singleton se crean la primera vez que se solicitan, y luego cada solicitud posterior utilizará la misma instancia. Si su aplicación requiere un comportamiento singleton, se recomienda que el contenedor de servicios administre la duración del servicio en lugar de implementar el patrón de diseño singleton y administrar la vida del objeto en la clase usted mismo.

Instancia [pre RTM solamente!]

Puede elegir agregar una instancia directamente al contenedor de servicios. Si lo hace, esta instancia se usará para todas las solicitudes posteriores (esta técnica creará una instancia de ámbito Singleton). Una diferencia clave entre los servicios de instancia y los servicios de Singleton es que el servicio de instancia se crea en ConfigureServices, mientras que el servicio de Singleton se carga de manera diferida la primera vez que se solicita.


Actualizado en RTM

Tenga en cuenta que en Asp.Net Core RTM docs Instancia se eliminó. La instancia es básicamente lo mismo que Singleton, pero tenían una semántica de inicialización diferente (Singleton se cargaba de forma diferida). Pero ahora no hay API AddInstance, solo AddSignleton que puede tomar una instancia ya creada.