Desentrañando la Inyección de Dependencias en ASP.NET Core: AddTransient, AddScoped y AddSingleton

Si trabajas con ASP.NET Core, seguro que te has encontrado con los métodos AddTransient, AddScoped y AddSingleton al configurar la inyección de dependencias. Y si alguna vez te has preguntado “¿Cuál debería usar y cuándo?”, este artículo es para ti. ☕

Vamos a explicar estas tres opciones con analogías claras y ejemplos prácticos para que nunca más dudes en cuál elegir. ¡Empezamos! 🚀

🔹 ¿Qué es la inyección de dependencias?

Antes de meternos en los detalles, hagamos un repaso rápido. La inyección de dependencias (DI, Dependency Injection) es un patrón de diseño que ayuda a gestionar la creación y el ciclo de vida de objetos dentro de una aplicación.

En ASP.NET Core, se usa un contenedor de dependencias donde registramos nuestros servicios con diferentes ciclos de vida: AddTransient, AddScoped y AddSingleton. Cada uno de estos métodos define cuánto tiempo vive un objeto antes de ser destruido y reemplazado por una nueva instancia.

1️⃣ AddTransient: Una instancia nueva en cada solicitud

Cuando registras un servicio con AddTransient, se crea una nueva instancia cada vez que se solicita.

📌 ¿Cuándo usarlo?

• Cuando necesitas un objeto sin estado que no necesita compartir datos entre solicitudes.
• Para servicios ligeros que se pueden crear y destruir sin impacto en el rendimiento.

📝 Ejemplo práctico

Supongamos que tenemos un servicio que genera IDs únicos en cada uso:

public interface IGeneradorId
{
    string Generar();
}

public class GeneradorId : IGeneradorId
{
    public string Generar() => Guid.NewGuid().ToString();
}

Y lo registramos en el contenedor de dependencias:

builder.Services.AddTransient<IGeneradorId, GeneradorId>();

Cada vez que inyectemos IGeneradorId en una clase, recibiremos una instancia nueva con un ID distinto.

2️⃣ AddScoped: Una instancia por solicitud HTTP

Con AddScoped, se crea una única instancia por cada solicitud HTTP, que se reutiliza dentro de la misma petición.

📌 ¿Cuándo usarlo?

• Cuando necesitas que una instancia sea compartida dentro de una única petición.
• Ideal para gestionar bases de datos, ya que compartir una misma instancia del contexto de EF Core evita problemas de concurrencia.

📝 Ejemplo práctico

Un uso común es con Entity Framework Core. El contexto de base de datos se suele registrar como Scoped para que todas las consultas dentro de una misma solicitud HTTP compartan la misma conexión:

builder.Services.AddDbContext<MiDbContext>(options =>
    options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")),
    ServiceLifetime.Scoped);

Si usáramos Transient, cada operación dentro de la misma solicitud abriría una nueva conexión a la base de datos, lo que no es eficiente. Y si usáramos Singleton, todas las solicitudes compartirían la misma instancia, lo que podría causar conflictos en consultas concurrentes.

3️⃣ AddSingleton: Una instancia única para toda la aplicación

Cuando registramos un servicio con AddSingleton, se crea una única instancia en toda la vida de la aplicación. Todas las solicitudes y servicios compartirán esa misma instancia.

📌 ¿Cuándo usarlo?

• Para servicios que deben persistir en toda la aplicación.
• Cuando el servicio no maneja datos de usuario y puede ser compartido sin problemas.

📝 Ejemplo práctico

Un caso ideal para Singleton es un servicio de configuración global:

public class ConfiguracionGlobal
{
    public string NombreAplicacion { get; set; } = "Mi App";
    public int Version { get; set; } = 1;
}

Y lo registramos así:

builder.Services.AddSingleton<ConfiguracionGlobal>();

Al ser un Singleton, cualquier parte de la aplicación que lo necesite accederá a la misma instancia con los mismos valores.

🧐 ¿Cuál elegir? Depende del caso

Ahora ya sabes cómo funcionan AddTransient, AddScoped y AddSingleton. ¿Tienes alguna experiencia con ellos? ¡Cuéntanos en los comentarios! 💬