Inyección de Dependencias

Usa el contenedor DI de NestJS 11 para ámbitos, proveedores personalizados y cableado de servicios comprobable.

Receta

Tarjeta de receta de referencia rápida: lista para copiar y pegar.

import { Module, Injectable, Inject } from "@nestjs/common";
 
@Injectable()
export class UsersRepository {
  findById(id: string) { return { id, name: "Ada" }; }
}
 
@Injectable()
export class UsersService {
  constructor(private readonly repo: UsersRepository) {}
 
  getUser(id: string) {
    return this.repo.findById(id);
  }
}
 
@Module({
  providers: [UsersRepository, UsersService],
  exports: [UsersService],
})
export class UsersModule {}

Cuándo usarlo: Cualquier servicio de NestJS que dependa de otro servicio, repositorio o cliente externo.

Ejemplo de trabajo

import { Module, Injectable, Inject } from "@nestjs/common";
import { Test } from "@nestjs/testing";
 
// Token de interfaz para implementaciones intercambiables
export const EMAIL_SENDER = Symbol("EMAIL_SENDER");
 
export interface EmailSender {
  send(to: string, subject: string): Promise<void>;
}
 
@Injectable()
export class SmtpEmailSender implements EmailSender {
  async send(to: string, subject: string) {
    console.log(`Enviando a ${to}: ${subject}`);
  }
}
 
@Injectable()
export class UsersService {
  constructor(
    @Inject(EMAIL_SENDER) private readonly email: EmailSender,
  ) {}
 
  async register(email: string) {
    await this.email.send(email, "¡Bienvenido!");
    return { email };
  }
}
 
@Module({
  providers: [
    UsersService,
    { provide: EMAIL_SENDER, useClass: SmtpEmailSender },
  ],
})
export class UsersModule {}
 
// Anulación de prueba
const testModule = await Test.createTestingModule({
  imports: [UsersModule],
})
  .overrideProvider(EMAIL_SENDER)
  .useValue({ send: async () => {} })
  .compile();

Lo que esto demuestra:

• Inyección de servicios en el constructor
• Tokens de proveedor personalizados con Symbol
• useClass para el enlace de interfaz a implementación
• overrideProvider para dobles de prueba

Análisis en profundidad

Cómo funciona

• NestJS crea un contenedor DI al iniciar
• @Injectable() registra una clase como proveedor
• Los tipos de parámetros del constructor determinan qué inyectar
• El contenedor resuelve el grafo de dependencias antes de atender las solicitudes

Ámbitos del proveedor

@Injectable({ scope: Scope.REQUEST })
export class RequestContextService {
  userId?: string;
}

Patrones de proveedor personalizados

Errores comunes

• Dependencias circulares - A inyecta B que inyecta A. Solución: forwardRef(() => B) o refactorizar la lógica compartida a un tercer servicio.
• Ámbito de solicitud en singleton - inyectar un servicio de solicitud en un singleton falla. Solución: usar ModuleRef o hacer que el consumidor también tenga ámbito de solicitud.
• Olvidar exports - el servicio no está disponible en el módulo importador. Solución: añadir al array exports.
• new Service() manual - omite la DI y la capacidad de prueba. Solución: inyectar siempre a través del constructor.
• Demasiados proveedores en un módulo - antipatrón de módulo "Dios". Solución: dividir en módulos de características.
• No anular en las pruebas - las pruebas acceden a la base de datos real. Solución: overrideProvider o useValue mock.

Alternativas

Preguntas frecuentes

Relacionado

• Conceptos básicos de NestJS - estructura del módulo
• Guards, Interceptors y Pipes - inyección transversal
• NestJS + Prisma/TypeORM - DI de la capa de datos
• Patrones de inyección de dependencias - DI agnóstica al framework
• Mejores prácticas de NestJS - lista de verificación de la sección

Versiones de la pila: Esta página fue escrita para Node.js 24.18.0 (LTS activa), npm 10+, TypeScript 5.6+, Express 5, Fastify 5 y NestJS 11.