That’s one small step for (a) man, one giant leap for mankind
Deze iconische woorden, gesproken door Neil Armstrong toen hij in 1969 als eerste mens het oppervlak van onze maan betrad, maken duidelijk dat hij, maar eigenlijk vooral NASA, een grote visie voor de toekomst hadden.
In mei dit jaar maakte één man ook voor DNN het verschil en zetten hij een “kleine” stap, maar met hem, de hele DNN-community een enorme strong.
DNN Platform visie
Die “kleine” stap was in werkelijkheid een groot pull-request van Andrew Hoefling waarin hij Dependency Injection (DI) toevoegt aan de DNN Core Platform Module patterns. Daarmee zet DNN Platform een grote en belangrijke stap richting .NET.Core.
Nu Microsoft heeft aangekondigd dat .NET.Core dè toekomst van .NET is, is de community druk bezig om DNN Platform – dat al sinds 2003(!) bestaat – stapje voor stapje naar .NET.Core te laten groeien. En Dependency Injection is dan een mooie eerste stap, want het is één van de kernwaardes van .NET.Core, maar ook van bijvoorbeeld Angular.
Injectie?
Dependency Injection is een software design pattern gebaseerd op de SOLID design principes van Object-Oriented-Programming (https://bit.ly/2Xywd7e). En kort door de bocht en wat abstract komt dit erop neer dat een class (een object) zich vooral bezig moeten houden met de taken waarvoor de class gemaakt is en niet met het aanmaken van afhankelijke (dependent) classes die de class nodig heeft om die taken te vervullen.
In DNN Platform is logischerwijs gekozen om het ASP.NET Core DI Framework te implementeren.
De grote sprong
De belangrijkste boodschap die ik je wil meegeven is dat DNN Platform én de community springlevend zijn en vol vertrouwen werken aan de toekomst van DNN Platform. De eerste stap is al gezet! De grote sprong komt!
Achtergrond
Ben je ontwikkelaar en vraag je je af waarom frameworks als .NET Core en Angular zoveel waarde hechten aan dependency injection? Lees dan verder!
In de onderstaande C# code voorbeelden werk ik stap voor stap toe naar DI met als doel je duidelijk te maken waarom DI zeker voor grote en complexe applicaties zo belangrijk is om deze beheersbaar, testbaar en uitbreidbaar te houden. Ben je er klaar voor?
Traditioneel zien veel classes er zo uit:
Het grootste probleem in bovenstaand voorbeeld zit in de afhankelijkheid die de Client class heeft op de Service class. Als de Service class wijzigt moet de Client class ook opnieuw gecompileerd worden en als de Service class bijvoorbeeld een extra constructor parameter krijgt, moet de Client class daar ook op worden aangepast. Voor een Service class die door veel andere classes wordt gebruikt zal het duidelijk zijn dat dit soort scenario’s een behoorlijke impact hebben.
Beter en al meer in lijn met de SOLID principes wordt het als de service ‘geïnjecteerd’ wordt. In dit geval via de constructor van de class. De Client class hoeft dan niet meer precies te weten hoe een Service object gemaakt wordt (hoewel dat in dit voorbeeld heel simpel was). De Client class is immers alleen gebruiker van de Service class en hoeft feitelijk niet te weten hoe dit object gemaakt moet worden.
Nóg beter wordt het als de concrete service wordt vervangen door een interface. De Client heeft dan helemaal geen afhankelijkheid meer met een concrete class. Het gebruik van een interface maakt het mogelijk om – ook naar de toekomst toe – allerlei uitbreidingen te maken, zonder dat de Client class daarvoor gewijzigd hoeft te worden – zolang de interface maar niet wijzigt.
En nu zijn we bijna waar Dependency Injection frameworks ons willen hebben.
De DI Container
Bovenstaande voorbeelden zijn leuk, maar geen enkele ontwikkelaar zit te wachten om zelf alle dependencies aan te leveren. In dit super simpele voorbeeld is het niet veel werk, maar in real-life applicaties lopen dergelijke constructies al heel snel uit de hand.
Gelukkig biedt een DI Container uitkomst en het onderstaande voorbeeld maakt duidelijk hoe eenvoudig het is geworden om objecten aan te maken of beter: op te vragen! De initialisatie van een DI container is wel wat werk, maar veel DI frameworks bieden mogelijkheden om dit proces (deels) te automatiseren. Uiteindelijk wint de eenvoud van gebruik alsmede de eenvoud waarmee objecten kunnen worden uitgebreid het van de ‘moeite’ om een DI container te initialiseren. Met name voor grote applicaties met heel veel classes maakt DI ontwikkeling en uitbreiding super eenvoudig!
Met de bovenstaande voorbeelden heb ik getracht je korte introductie van DI te geven en waarom dit design principe momenteel in zoveel frameworks als key feature terug komt.
Happy coding!
Meer weten over Dependency Injection en DNN? Neem contact op via +31-33-433 51 51 of stuur ons een bericht via het contactforumulier.