Convenciones de inyección de dependencias en .NET: tiempos de vida, ámbitos y la trampa de la dependencia cautiva

Qué es

La documentación de .NET describe un contenedor integrado: los servicios se agregan a un IServiceCollection al arrancar (AddTransient, AddScoped, AddSingleton, o variantes con clave), BuildServiceProvider o el host genérico crea el IServiceProvider, y quienes consumen reciben las dependencias mediante un constructor público. Los servicios transient se crean cada vez que se solicitan; los scoped, una vez por ámbito, que en ASP.NET Core es la solicitud; los singleton, una vez para toda la vida del contenedor. El contenedor libera lo que creó: las instancias transient y scoped al final de su ámbito, los singleton al apagarse. Cuando un tipo tiene varios constructores, se elige el que tiene más parámetros resolubles por DI, y la ambigüedad lanza una excepción.

Por qué importa

Quienes vienen de Spring (singleton por defecto) o de marcos sin contenedor tienden a registrar todo como singleton o a resolver servicios a mano. La página de directrices llama al fallo resultante una dependencia cautiva: un servicio de vida más larga retiene uno de vida más corta, de modo que un DbContext «por solicitud» capturado por un singleton pasa a compartirse silenciosamente entre todas las solicitudes. La página de tiempos de vida indica que un servicio scoped no debe resolverse desde un singleton, ni por inyección de constructor ni mediante IServiceProvider; la solución documentada es crear un ámbito explícito con IServiceScopeFactory.

Cómo aplicarlo

• Usar transient por defecto para servicios sin estado, scoped para estado por solicitud (DbContext, unidad de trabajo), y singleton solo para estado compartido, seguro para hilos y costoso; las directrices dicen que los singleton deben ser seguros para hilos y advierten sobre el acoplamiento y la memoria.
• Depender de interfaces en los constructores y mantenerlos libres de trabajo más allá de la asignación.
• Nunca llamar a Dispose sobre un servicio inyectado, y no registrar tipos IDisposable como transient cuando puedan resolverse desde el proveedor raíz; las directrices dicen que esas instancias se retienen hasta que se libera el contenedor.
• No llamar a BuildServiceProvider mientras se configuran los servicios y no usar GetService como localizador de servicios; ambos se enumeran como antipatrones.
• Mantener activa la validación de ámbitos: el host de desarrollo comprueba que los servicios scoped no se resuelvan desde la raíz ni se inyecten en singleton, y validateScopes: true en BuildServiceProvider hace lo mismo en otros lugares.
• En servicios hospedados o en segundo plano, inyectar IServiceScopeFactory y crear un ámbito por unidad de trabajo.

Trampas

El acceso estático al proveedor (un ApplicationServices capturado) figura como algo que hay que evitar: las directrices dicen que los beneficios de DI se pierden cuando se mezcla con acceso estático a objetos. Guardar configuración o datos de usuario en el contenedor en lugar de usar el patrón de opciones. Los servicios con clave necesitan [FromKeyedServices("key")] en el parámetro. Registrar un servicio dos veces es válido y fácil de pasar por alto.