Dependency injection förklarat

Inom programmering är ett beroende helt enkelt något som en klass eller funktion behöver för att utföra sitt arbete. En klass för "Car" kan till exempel vara beroende av en klass för "Engine" för att kunna köra.

Om ni skapar dessa beroenden manuellt inuti varje klass kan koden bli hårt kopplad. Då blir den svårare att testa, ändra och återanvända.

Dependency Injection (DI) hjälper oss att hantera dessa relationer bättre och gör applikationerna mer flexibla.

Inversion of Control (IoC) är en designprincip där kontrollflödet vänds på. I stället för att er kod anropar ett bibliotek är det ett ramverk som anropar er kod och hanterar skapandet av objekt samt deras livscykel.

• Traditionellt: Ni går in i köket och lagar er egen måltid (er kod skapar sina beroenden).
• IoC: Ni beställer från en meny och kocken tillagar och serverar måltiden (ramverket skapar och tillhandahåller beroenden).

NestJS bygger på IoC, vilket innebär att ramverket ansvarar för att skapa och hantera många delar av applikationen.

Dependency Injection (DI) är ett specifikt mönster som används för att implementera Inversion of Control. Det innebär att beroenden "injiceras" i en komponent i stället för att komponenten skapar dem själv.

I stället för att en klass säger "Jag behöver en Engine, så jag skriver new Engine()" säger den "Jag behöver en Engine, ge mig en."

Denna "leverans" av beroenden sker vanligtvis via klassens konstruktor, en setter-metod eller injicering i en egenskap.

DI ger flera viktiga fördelar när ni bygger robusta applikationer:

• Bättre testbarhet: Byt enkelt ut verkliga beroenden mot simulerade versioner under testning.
• Ökad underhållbarhet: Ändringar i ett beroende kräver inte att ni ändrar varje klass som använder det.
• Förbättrad återanvändbarhet: Komponenterna blir mer generella och kan användas i olika sammanhang.
• Mindre koppling: Klasser är inte direkt beroende av konkreta implementationer, vilket gör systemen mer flexibla.

I NestJS kallas nästan allt som kan injiceras för en Provider. Det omfattar services, repositories, factories, helpers med mera.

Dekoratören @Injectable() markerar en klass som en provider. Det talar om för NestJS runtime att klassen kan hanteras av dess Dependency Injection-container.

När NestJS ser @Injectable() vet det hur en instans av klassen ska skapas och tillhandahållas till andra komponenter som behöver den.

NestJS använder främst injektering via konstruktor. Det innebär att ni deklarerar de beroenden som en klass behöver direkt i dess konstruktor.

Genom att ange beroendets typ i konstruktorn hittar NestJS DI-container automatiskt en instans av beroendet och tillhandahåller den när klassen skapas.

Det här är ett kraftfullt och tydligt sätt att hantera beroenden utan att skapa instanser manuellt, och det främjar tydliga relationer mellan komponenterna.

Föreställ er att ni har en AppService som hanterar affärslogik och en AppController som hanterar HTTP-förfrågningar. AppController behöver AppService för att utföra sina uppgifter.

Med DI skapar ni inte servicen inuti controllern. I stället deklarerar ni den i konstruktorn, så tillhandahåller NestJS den:

// app.service.ts
@Injectable()
export class AppService {
  getHello(): string {
    return 'Hello World!';
  }
}

// app.controller.ts
@Controller()
export class AppController {
  constructor(private readonly appService: AppService) {}

  @Get()
  getHello(): string {
    return this.appService.getHello();
  }
}

Det här är ett konceptuellt kodexempel som illustrerar strukturen.

Vi ska titta på ett förenklat exempel som visar grundidén bakom injektering via konstruktor. Vi simulerar "containern" manuellt för att göra exemplet körbart.

Lägg märke till att AppService inte skapar LoggerService själv utan tar emot den. Det är själva kärnan i DI.

Prova att köra den här koden:

För att NestJS ska känna till era providers måste de registreras i en modul. Moduler är klasser som dekorerats med @Module().

Arrayen providers i en moduls dekoratör talar om för NestJS vilka klasser som ska hanteras av DI-containern.

Exempel:

@Module({
  imports: [],
  controllers: [AppController],
  providers: [AppService, LoggerService], // Register your providers here!
})
export class AppModule {}

Den här konfigurationen säkerställer att NestJS vet var och hur AppService ska skapas (samt dess beroenden, som LoggerService) när AppController behöver den.

Du har lärt dig de grundläggande koncepten bakom NestJS-arkitekturen:

• Inversion of Control (IoC): Ramverket hanterar skapandet av objekt och deras livscykel.
• Dependency Injection (DI): Ett mönster där beroenden tillhandahålls till en klass, vanligtvis via dess konstruktor.
• Providers: NestJS-komponenter (till exempel tjänster) som är markerade med @Injectable() och kan injiceras.
• Constructor Injection: Det huvudsakliga sättet som NestJS levererar beroenden på.

Att förstå DI är avgörande för att bygga skalbara och lättunderhållna NestJS-applikationer. I nästa lektion utforskar vi Data Transfer Objects (DTO:er) och valideringspipes!