Dependency injection uitgelegd

Bij programmeren is een afhankelijkheid simpelweg iets wat een klasse of functie nodig heeft om haar taak uit te voeren. Een klasse "Car" kan bijvoorbeeld afhankelijk zijn van een klasse "Engine" om te kunnen rijden.

Als je deze afhankelijkheden handmatig in elke klasse maakt, kan dat leiden tot sterk gekoppelde code. Daardoor wordt je code moeilijker te testen, te wijzigen en opnieuw te gebruiken.

Dependency injection (DI) helpt je deze relaties beter te beheren, waardoor je applicaties flexibeler worden.

Inversion of Control (IoC) is een ontwerpprincipe waarbij de besturingsstroom wordt omgekeerd. In plaats van dat je code een bibliotheek aanroept, roept een framework jouw code aan en beheert het het maken en de levensduur van objecten.

• Traditioneel: je gaat de keuken in en kookt je eigen maaltijd (je code maakt de afhankelijkheden).
• IoC: je bestelt van een menu en de chef bereidt en serveert je maaltijd (het framework maakt de afhankelijkheden en stelt ze beschikbaar).

NestJS is gebouwd op IoC. Dat betekent dat het de verantwoordelijkheid neemt voor het maken en beheren van veel onderdelen van je applicatie.

Dependency injection (DI) is een specifiek patroon om Inversion of Control te implementeren. Het betekent dat afhankelijkheden in een onderdeel worden "geïnjecteerd", in plaats van dat het onderdeel ze zelf maakt.

In plaats van dat een klasse zegt: "Ik heb een Engine nodig, dus ik maak new Engine()", zegt deze: "Ik heb een Engine nodig, geef me er een."

Dit "geven" van afhankelijkheden gebeurt meestal via de constructor van de klasse, een setter-methode of property-injectie.

DI biedt verschillende belangrijke voordelen voor het bouwen van robuuste applicaties:

• Betere testbaarheid: verwissel tijdens tests eenvoudig echte afhankelijkheden voor nagebootste versies.
• Betere onderhoudbaarheid: wijzigingen aan een afhankelijkheid vereisen niet dat je elke klasse aanpast die deze gebruikt.
• Betere herbruikbaarheid: onderdelen worden algemener en kunnen in verschillende contexten worden gebruikt.
• Minder koppeling: klassen zijn niet rechtstreeks afhankelijk van concrete implementaties, waardoor systemen flexibeler worden.

In NestJS wordt bijna alles wat geïnjecteerd kan worden een provider genoemd. Hieronder vallen services, repositories, factories, hulpprogramma's en meer.

De decorator @Injectable() markeert een klasse als provider. Daarmee laat je de NestJS-runtime weten dat deze klasse door de container voor dependency injection kan worden beheerd.

Wanneer NestJS @Injectable() ziet, weet het hoe het een exemplaar van die klasse moet maken en beschikbaar moet stellen aan andere onderdelen die dit nodig hebben.

NestJS gebruikt voornamelijk injectie via de constructor. Dat betekent dat je de afhankelijkheden die een klasse nodig heeft rechtstreeks in de constructor declareert.

Door het type van de afhankelijkheid in de constructor op te geven, vindt de DI-container van NestJS automatisch een exemplaar van die afhankelijkheid en stelt dit beschikbaar wanneer je klasse wordt gemaakt.

Dit is een krachtige en overzichtelijke manier om afhankelijkheden te beheren zonder ze handmatig te instantiëren, en bevordert duidelijke relaties tussen onderdelen.

Stel dat je een AppService hebt die bedrijfslogica verwerkt en een AppController die HTTP-aanvragen verwerkt. De AppController heeft de AppService nodig om zijn taken uit te voeren.

Met DI maak je de service niet in de controller. In plaats daarvan declareer je deze in de constructor en stelt NestJS de service beschikbaar:

// 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();
  }
}

Dit is een conceptueel fragment om de structuur te illustreren.

Bekijk een vereenvoudigd voorbeeld dat het kernidee van injectie via de constructor demonstreert. We simuleren het gedeelte met de "container" handmatig, zodat je de code kunt uitvoeren.

Let erop dat AppService niet zelf LoggerService maakt, maar deze ontvangt. Dat is de essentie van DI.

Probeer deze code uit te voeren:

Om ervoor te zorgen dat NestJS je providers kent, moeten ze binnen een module worden geregistreerd. Modules zijn klassen met de decorator @Module().

De array providers binnen de decorator van een module vertelt NestJS welke klassen door de DI-container moeten worden beheerd.

Bijvoorbeeld:

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

Deze configuratie zorgt ervoor dat NestJS weet waar het AppService moet vinden en hoe het deze moet maken wanneer AppController AppService nodig heeft (en ook de afhankelijkheden ervan, zoals LoggerService).

Je hebt de fundamentele concepten achter de architectuur van NestJS geleerd:

• Inversion of Control (IoC): Het framework beheert het aanmaken en de levensduur van objecten.
• Dependency Injection (DI): Een patroon waarbij afhankelijkheden aan een klasse worden meegegeven, meestal via de constructor.
• Providers: NestJS-componenten (zoals services) die zijn gemarkeerd met @Injectable() en kunnen worden geïnjecteerd.
• Constructor Injection: De belangrijkste manier waarop NestJS afhankelijkheden beschikbaar maakt.

Inzicht in DI is cruciaal voor het bouwen van schaalbare en onderhoudbare NestJS-applicaties. In de volgende les verken je Data Transfer Objects (DTO's) en validatiepijplijnen!