Thomas Mahringer Selbstständig

„TypeScript ist cool! Mit einer einfachen Registry und TypeScript Decorators lassen sich Klassen so manipulieren, dass man beim Instanziieren neue Werte in die Parameter ihrer Konstruktoren injizieren kann. Diese simple Dependency Injection genügt für viele Anwendungsfälle und lässt sich natürlich noch ausbauen.“

Dependency Injection hat sich bei den meisten Softwareprojekten, Frameworks und Apps durchgesetzt. Dennoch ist es erstaunlich, wie viele Fragen man in diversen Foren im Kontext von JavaScript Frameworks zu diesem Thema findet. Muss Dependency Injection kompliziert sein? Wir meinen nicht. Mit TypeScript MetaData und Decorators lässt sich eine sehr kompakte, aber wirkungsvolle Dependency Injection aufbauen.

Spätestens seit dem Java Spring Framework hat sich Inversion of Control oder Dependency Injection (DI) als Designpattern etabliert. Die damals noch nicht so verbreitete Idee war es, Methoden, Klassen und Module so zu entwerfen, dass sie durch ihre Schnittstellen wirklich vollständig beschrieben sind. Das bedeutet, dass sie kein implizites oder globales Wissen mitbringen müssen, um korrekt zu funktionieren. Ein Gegenbeispiel dazu wären verschiedene Arten von Service-Locator-Patterns oder, noch schlimmer, mehrere globale Objekte, die Services bereitstellen. Diese Muster sind Antimuster, bei denen Methoden wissen, wo sie nachsehen müssen, um benötigte Services zu beziehen, z. B. für Datenzugriff, Authentifizierung usw. Der Zugriff auf die Services erfolgt global, beispielsweise über static-Methoden wie ServiceLocator.getDataSource(), DataAccess.getDataSource() oder Security.getAuthenticationService(). Je mehr von diesen globalen Abhängigkeiten umherschwirren, desto undurchschaubarer wird der Code, und er lässt sich vor allem nicht mehr modular Unit-testen, da sämtliche globalen Objekte in den richtigen Testzustand versetzt werden müssen. Bei der DI oder Inversion of Control läuft es eben umgekehrt: Nicht die einzelnen Codefragmente wissen, woher sie Services beziehen, sondern Letztere werden ihnen beim Aufruf einfach mitgegeben, z. B. als Konstruktorargumente. Damit sind jedes Codestück, jede Klasse und Methode wirklich eindeutig durch ihre Schnittstellen definiert.

Was hat das mit JavaScript zu tun?

In der guten alten Zeit, in der Web-Apps serverseitig, z. B. über MVC-Frameworks, gerendert wurden, beschränkte sich JavaScript auf die dynamische Manipulation des DOMs und evtl. auch noch auf Ajax-Datentransfer. jQuery, ähnliche Frameworks und ihr Programmiermodell saßen fest im Webstack-Sattel. Wie Sie wissen, hat sich die Situation mit voll ausgewachsenen JavaScript-Clientapplikationen stark verändert, denn sie sind eigentlich Rich Clients (Single-Page-Applikationen), die mit Backends kommunizieren. Statt jQuery und Co. finden wir MVVC-Patterns und reaktive Programmierung. Frameworks wie Ract.js, Angular und Vue.js sind wohlbekannt, und mit Progressive Web Apps wird die Lücke zwischen echter App und Web-App nochmal deutlich verkleinert.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Windows Developer 6.19 - "Challenge Accepted"

Alle Infos zum Heft
579889816Dependency Injection in unter 200 Zeilen Code
X
- Gib Deinen Standort ein -
- or -