En tres lecciones distintas del Módulo 7 —ASP.NET Core, Blazor y MAUI— apareció el mismo mensaje de pasada: "esto es inyección de dependencias, se estudiará en profundidad en el Módulo 8". Ha llegado ese momento. Esta lección explica primero el problema de fondo que resuelve la inversión de control (acoplar código a implementaciones concretas dificulta el cambio y, sobre todo, dificulta las pruebas), después compara las distintas formas de inyectar una dependencia, y por último aplica todo eso al caso más concreto de BiblioTech: extraer una interfaz IRepositorioBiblioteca a partir de las cuatro formas de persistencia construidas en el Módulo 5 (texto, JSON, SQLite, Entity Framework Core), de modo que Biblioteca pueda usar cualquiera de ellas sin saber cuál está usando en cada momento. De paso, se explica en detalle el contenedor de servicios de ASP.NET Core que ya usaste, sin profundizar, en la lección de Minimal APIs.

1. El problema: acoplamiento fuerte y dificultad para testear
2. La inversión de control como solución
3. Inyección por constructor frente a por propiedad o método
4. Extrayendo IRepositorioBiblioteca de los repositorios del Módulo 5
5. Biblioteca inyectada con IRepositorioBiblioteca
6. Contenedores de DI en profundidad: AddSingleton/AddScoped/AddTransient
7. Ejemplo completo: registrar y resolver en ASP.NET Core

Imagina que Biblioteca guarda y carga su catálogo llamando directamente a los métodos de persistencia en SQLite construidos en el Módulo 5:

Este diseño tiene dos problemas serios, aunque el código "funcione":

• Acoplamiento fuerte: Biblioteca queda ligada a SQLite de forma permanente. Cambiar a JSON, o a Entity Framework, o a un tercer sistema de persistencia futuro, obliga a modificar Biblioteca directamente —una clase que, en principio, solo debería preocuparse de la lógica de préstamos y catálogo, no de los detalles de cómo se guardan los datos.
• Dificultad para testear: para escribir una prueba unitaria (Lección 4 de este módulo) sobre la lógica de Biblioteca, haría falta una base de datos SQLite real disponible, con datos conocidos, cada vez que se ejecuten los tests. Eso hace las pruebas lentas, frágiles (dependen de un fichero externo) y difíciles de ejecutar en cualquier máquina sin preparación previa.

La inversión de control (IoC) invierte quién decide qué implementación concreta se usa: en vez de que Biblioteca cree directamente su propia dependencia de persistencia (new SqliteConnection(...)), la recibe ya construida desde fuera, a través de una abstracción (una interfaz) que no revela los detalles de la implementación concreta:

Biblioteca deja de decidir "cómo" se persisten los datos: solo declara que necesita algo que cumpla el contrato IRepositorioBiblioteca, y quien la construye decide qué implementación concreta le entrega. La inyección de dependencias es, precisamente, la técnica mediante la cual esa dependencia "entra" desde fuera —por constructor, propiedad o método, como ve el siguiente apartado— en vez de crearse internamente con new. Es la forma más común de aplicar el principio de inversión de control.

Existen tres formas de inyectar una dependencia en una clase:

La inyección por constructor es la práctica recomendada por defecto en la inmensa mayoría de casos, por dos razones: hace la dependencia obligatoria (no se puede crear una Biblioteca sin proporcionar su repositorio, lo que elimina de raíz cualquier NullReferenceException por olvido), y hace explícito, con solo mirar la firma del constructor, de qué depende exactamente la clase. La inyección por propiedad se reserva para dependencias genuinamente opcionales (por ejemplo, un servicio de registro/logging que puede faltar sin que el objeto deje de funcionar); la inyección por método, para dependencias que solo hacen falta durante una operación puntual, no durante toda la vida del objeto.

El Módulo 5 construyó cuatro formas distintas de persistir el catálogo de BiblioTech: texto plano (GuardarCatalogoTexto/CargarCatalogoTexto), JSON (GuardarEstadoJson/CargarEstadoJson), SQLite con ADO.NET (GuardarLibrosEnSqlite/CargarLibrosDesdeSqlite) y Entity Framework Core (BibliotecaDbContext). Las cuatro resuelven, en el fondo, la misma pregunta: "guarda este catálogo" y "recupérame el catálogo guardado". Esa es la señal exacta de que hace falta una interfaz común:

Cada mecanismo del Módulo 5 pasa a ser una clase independiente que implementa esta interfaz, reutilizando la lógica ya escrita entonces:

Ninguna de estas cuatro clases modifica la lógica de persistencia que ya construiste en el Módulo 5 —solo la reorganiza detrás de un contrato común. RepositorioEntityFramework, en particular, recibe su propio BibliotecaDbContext también por inyección de constructor: la inyección de dependencias se aplica en cadena, no solo en el punto más externo.

Con la interfaz ya definida, Biblioteca deja de conocer cualquier detalle concreto de persistencia:

Biblioteca es idéntica en ambos casos: lo único que cambia es qué implementación concreta de IRepositorioBiblioteca se le entrega al construirla. Este es exactamente el objetivo de la inversión de control planteado en el apartado 2, ya resuelto de forma concreta sobre el dominio de BiblioTech. Además, como se anticipó en el apartado 1, esta misma estructura es la que permitirá, en la Lección 4, sustituir IRepositorioBiblioteca por un doble de prueba (mock) sin necesitar ningún fichero ni base de datos real durante los tests.

La lección de ASP.NET Core (Módulo 7) introdujo el contenedor de servicios de forma básica, con builder.Services.AddSingleton<Biblioteca>(). Ahora que conoces la teoría completa de la inyección de dependencias, es el momento de entender por qué existen tres métodos distintos de registro, no solo AddSingleton:

AddScoped<IRepositorioBiblioteca, RepositorioEntityFramework>() registra dos tipos: el primero es el tipo que se pedirá (la interfaz), el segundo es la implementación concreta que el contenedor debe construir cuando alguien pida ese tipo. Cuando el endpoint declara Biblioteca biblioteca como parámetro, ASP.NET Core resuelve automáticamente toda la cadena: construye un RepositorioEntityFramework, que a su vez necesita un BibliotecaDbContext (también registrado), y con ese repositorio ya construido, construye finalmente la Biblioteca que el endpoint recibe. Ninguna de estas construcciones intermedias la escribe el programador a mano: el contenedor de DI la resuelve leyendo los constructores de cada clase registrada.

AddScoped para Biblioteca (en vez de AddSingleton, como se vio de forma simplificada en el Módulo 7) es ahora la elección correcta: como Biblioteca depende de un BibliotecaDbContext —que ya sabes que debe vivir solo durante una petición—, Biblioteca misma debe tener el mismo ciclo de vida que su dependencia, o arrastraría un DbContext obsoleto entre peticiones distintas.

Uniendo todas las piezas anteriores, así queda el registro completo de servicios de una API de BiblioTech que usa Entity Framework Core como mecanismo de persistencia, con Biblioteca inyectada con IRepositorioBiblioteca en vez de acoplada directamente a EF Core:

Para probar con otro mecanismo de persistencia —por ejemplo, en un entorno de pruebas manuales sin base de datos— bastaría con cambiar una sola línea:

Este es el resultado práctico de haber invertido el control desde el apartado 2: cambiar por completo el mecanismo de persistencia de toda la API es, ahora, una única línea en Program.cs, en vez de una modificación dispersa por todo Biblioteca.

• Registrar Biblioteca como AddSingleton cuando depende de un BibliotecaDbContext Scoped: el contenedor de ASP.NET Core lo detecta y lanza una excepción al arrancar (captive dependency, una dependencia de vida corta "atrapada" dentro de un objeto de vida más larga). El ciclo de vida de una clase nunca debe ser más largo que el de sus dependencias.
• Inyectar por propiedad "por comodidad" en vez de por constructor: hace que la dependencia parezca opcional cuando en realidad es obligatoria, y permite crear el objeto en un estado incompleto (sin la dependencia asignada) que solo falla más tarde, al usarla.
• Confundir la interfaz IRepositorioBiblioteca con "una capa inútil de más": parece redundante mientras solo hay una implementación real, pero su valor aparece justo cuando hace falta cambiar de implementación (apartado 7) o sustituirla por un doble de prueba (Lección 4).
• Consejo: si al diseñar una clase te preguntas "¿esto debería ser new aquí dentro, o recibido desde fuera?", la pregunta de oro es: ¿alguna vez necesitaré sustituir esta dependencia por otra implementación, o por una versión de prueba? Si la respuesta es sí, inyéctala.

1. Define una interfaz INotificador con un único método void Notificar(string mensaje), y dos implementaciones: NotificadorConsola (que use Console.WriteLine) y NotificadorSilencioso (que no haga nada). Modifica Biblioteca para que reciba un INotificador por constructor y lo use dentro de RegistrarPrestamo en vez de llamar directamente a Console.WriteLine.

2. En el registro de servicios de ASP.NET Core del apartado 7, explica por qué IRepositorioBiblioteca y Biblioteca deben registrarse como AddScoped (y no AddSingleton) mientras dependan, directa o indirectamente, de BibliotecaDbContext.

interface INotificador
{
    void Notificar(string mensaje);
}

class NotificadorConsola : INotificador
{
    public void Notificar(string mensaje) => Console.WriteLine(mensaje);
}

class NotificadorSilencioso : INotificador
{
    public void Notificar(string mensaje) { /* no hace nada */ }
}

class Biblioteca
{
    private readonly IRepositorioBiblioteca _repositorio;
    private readonly INotificador _notificador;

    public List<Prestamo> Prestamos { get; } = new List<Prestamo>();

    public Biblioteca(IRepositorioBiblioteca repositorio, INotificador notificador)
    {
        _repositorio = repositorio;
        _notificador = notificador;
    }

    public void RegistrarPrestamo(Prestamo prestamo)
    {
        Prestamos.Add(prestamo);
        _notificador.Notificar($"Prestamo de '{prestamo.Libro.Titulo}' registrado.");
    }
}

BibliotecaDbContext se registra con AddDbContext (equivalente a AddScoped) porque no está pensado para compartirse entre peticiones concurrentes (lección de ASP.NET Core, Módulo 7). Si IRepositorioBiblioteca (que envuelve ese DbContext) o Biblioteca (que depende de IRepositorioBiblioteca) se registraran como AddSingleton, la primera petición HTTP dejaría "atrapado" dentro de ese singleton un BibliotecaDbContext que debería haberse desechado al terminar esa petición, y las peticiones siguientes reutilizarían un contexto obsoleto o ya liberado, provocando errores en tiempo de ejecución.

En esta lección has entendido el problema de fondo que resuelve la inversión de control (acoplamiento fuerte y dificultad para testear), comparado la inyección por constructor —la recomendada por defecto— con la inyección por propiedad y por método, extraído una interfaz IRepositorioBiblioteca que unifica las cuatro formas de persistencia del Módulo 5 detrás de un contrato común, e inyectado esa interfaz en Biblioteca para desacoplarla de cualquier mecanismo concreto. También has entendido en profundidad, por fin, la diferencia entre AddSingleton, AddScoped y AddTransient en el contenedor de servicios de ASP.NET Core, que solo se había mencionado de pasada en el Módulo 7.

Todo este trabajo de desacoplar Biblioteca de sus dependencias concretas tiene un beneficio que todavía no has explotado: ahora es posible sustituir IRepositorioBiblioteca por una versión de prueba que no toque ningún fichero ni base de datos real. Esa es, precisamente, la puerta de entrada a la siguiente lección: pruebas unitarias, donde IRepositorioBiblioteca se sustituirá por un doble de prueba (mock) para verificar la lógica de Biblioteca de forma rápida, aislada y repetible.