Im Artikel Quo Vadis, .NET? habe ich auf die Microsoft Extensions hingewiesen und darauf, dass diese auch mit klassischen .NET Framework-Anwendungen nutzbar sind. Allerdings stellt sich die Frage, warum man das tun sollte. In diesem Beitrag möchte ich genau diese Frage beantworten.
Die Rolle der Microsoft Extensions
Das klassische .NET Framework stellt dem Anwendungsentwickler mit der Base Class Library (BCL) grundlegende Plattform-Features zur Verfügung (Datentypen, I/O, Threading, …), sowie grundlegende Features, die zwar nicht plattformabhängig sind, die man aber heutzutage im Rahmen eines Frameworks erwartet (Konfiguration, Logging, …).
Hinweis: Man findet unterschiedliche Definitionen für “BCL”, die teilweise enger gefasst sind, teilweise vergleichbar und teilweise darüber hinaus gehen (Wikipedia, Blog, Blog und Stack Overflow). In der Microsoft-Dokumentation selbst findet man den Begriff hingegen immer weniger.
Mit .NET Standard hat Microsoft die Vorgabe für die plattformabhängigen Anteile geschaffen (zumindest soweit diese auf allen Plattformen verfügbar sein sollen). Die Microsoft Extensions adressieren plattformunabhängige Anteile und schließen so eine Lücke, die sich sonst aus Sicht eines Anwendungsentwicklers auftun würde. Nur der Vollständigkeit halber: Eine dritte Gruppe sind die Windows-abhängigen Features, die im Rahmen des Windows Compatibility Pack zur Verfügung gestellt werden.
Microsoft hat die Microsoft Extensions nun aber nicht aus dem Ansinnen heraus entwickelt, .NET Framework-Features nachzubauen. Vielmehr sind sie im Kontext von ASP.NET Core – aufgrund konkreter Anforderungen und nicht zuletzt im Kontext von realen Anwendungsszenarien – entstanden. Sie bieten daher nicht nur Funktionalitäten, die man aus dem .NET Framework im Grundsatz kennt (etwa Konfiguration), sondern auch Dinge, die in der klassischen BCL nicht vorhanden sind, zum Beispiel Dependency Injection. Und spätestens wenn man in die Details schaut, kann man jede Verwandtschaft mit dem klassischen .NET Framework ausschließen.
Microsoft Extensions für .NET Framework
Wenn dem .NET Framework-Entwickler die Features der Microsoft Extensions also größtenteils ohnehin bereits zur Verfügung stehen – für Themen wie Dependency Injection gibt es genügend Alternativen – welchen Grund sollte es also geben, die Microsoft Extensions dennoch in diesem Kontext einzusetzen?
Bei bestehenden Anwendungen lautet die Antwort in vielen Fällen: Es gibt keinen! Gerade Anwendungen, die hauptsächlich der Wartung unterliegen und bei denen keine große Weiterentwicklung abzusehen ist, bringen die Microsoft Extensions nur zusätzliche Komplexität ohne echten Mehrwert.
Etwas anders sieht das aber bei Anwendungen aus, die einer konstanten Weiterentwicklung unterliegen. Hier kann eine Migration durchaus sinnvoll sein. Und bei Neuentwicklungen, ebenso wie bei der Entwicklung von wiederverwendbaren Bibliotheken, kann man von vorne herein auf die Microsoft Extensions setzen.
Hier einige Gründe, die für den Einsatz der Microsoft Extensions – auch im Rahmen von .NET Framework – sprechen:
Vorbereitung auf eine (spätere) Migration. Wenn eine Migration auf .NET Core ohnehin ansteht, stellt sich die Frage nach dem “ob” gar nicht. Aber auch, wenn dies für einen späteren Zeitpunkt angedacht ist, ist eine Migration auf die Microsoft Extensions sinnvoll. Man kann dies ggf. sogar für einzelne Features getrennt machen. Diese “Migration in kleinen Schritten” hilft dabei, Big-Bang-Szenarien zu vermeiden und reduziert so das Risiko.
Modernere, flexiblere Implementierungen. Die bestehenden Implementierungen im .NET Framework oder gängigen Bibliotheken sind nicht immer ausreichend oder kommen zum Preis einer externen Abhängigkeit. Sei es der Wunsch, Konfigurationswerte aus der Datenbank zu lesen, die dann aber nicht als AppSettings verfügbar sind, oder ein Logging-Framework wie log4net, das sich als Abhängigkeit quer durch den Code zieht.
Die Microsoft Extensions sind konsequent auf Abstraktion und Erweiterbarkeit ausgelegt. Konfigurationswerte aus unterschiedlichen Quellen zu liefern, ohne dass der nutzende Code dafür geändert werden muss, ist Teil des Konzeptes. Gleiches gilt für das Logging oder auch Dependency Injection: Aufrufender Code arbeitet konsequent gegen Schnittstellen, die eigentliche Implementierung dahinter kann flexibel nach den eigenen Bedürfnissen ausgetauscht werden.
Performante Implementierungen. Die Microsoft Extensions sind im Rahmen von ASP.NET Core aus der Praxis heraus entwickelt worden. Die vorhandenen Konzepte und Implementierungen bieten einen pragmatischen Umfang und sie sind im Hinblick auf Performance optimiert.
Eine Konsequenz daraus ist, dass die einzelnen Funktionalitäten beim direkten Vergleich mit alternativen Bibliotheken nicht alle Features anbieten. So bietet Dependency Injection zum Beispiel weder Property Injection noch ein Konzept für Interceptoren an – typische Funktionalitäten, die nahezu jeder DI-Container im Gepäck hat. Aber man hat die Wahl: Nutzt man den DI-Container der Microsoft Extensions, bekommt man eine performante Umsetzung; will man nicht auf erweiterten Features verzichten, kann man problemlos auch alternative DI-Container einklinken.
Architektur. Die Microsoft Extensions sind konsequent auf Abstraktion und Erweiterbarkeit ausgelegt. Die Nutzung eines Features bedeutet eben nicht, dass man sich damit auf Gedeih und Verderb den in den Microsoft Extensions vorhandenen Umsetzungen ausliefert. Man kann ohne Probleme eigene Konfigurationen anbinden, ein alternatives Logging-Framework nutzen, oder seinen bevorzugten DI-Container einbinden (weitere Details hierzu folgen in einem separaten Artikel).
Standardisierung. Konfiguration oder Logging sind typische Basisfunktionalitäten, die auch von anderen Bibliotheken benötigt werden. Man kann durchaus erwarten, dass Bibliotheken, die zum Beispiel heute über Mechanismen aus System.Configuration eine ConfigurationSection bereitstellen, in Zukunft auf die Microsoft Extensions schwenken werden. Das gilt insbesondere, da es derzeit einen Trend zu .NET Standard gibt.
Zukunftssicherheit. Selbst wenn eine Anwendung auf absehbare Zeit weiterhin das .NET Framework nutzt – etwa, weil sie WCF benötigt – bezieht sich diese Abhängigkeit ja nicht auf den gesamten Code. Man kann also durchaus Teilbereiche auf .NET Standard oder sogar .NET Core umstellen. Denn Fakt ist: Die im .NET Framework vorhandene Funktionalität ist eingefroren, Neuentwicklungen werden im Bereich .NET Core und basierend auf .NET Standard stattfinden. Wer zukunftsfähig bleiben will, muss sich dieser Realität stellen.
Fazit
Wenn die von mir angeführten Gründe überzeugend sind, steht dem Einsatz der Microsoft Extensions eigentlich nichts entgegen, oder?
Abgesehen davon…
… dass man sich als klassischer .NET Framework-Entwickler mit den bestehenden Funktionalitäten auskennt, während die Microsoft Extensions neu sind.
… dass man nicht beurteilen kann, ob sie die eigenen Anforderungen erfüllen.
… dass man nicht weiß, wie man sie möglichst effizient nutzt,
… wie man sie erweitert,
… und wo man ggf. auch davon abweicht.
Anders ausgedrückt: Solange man sich nicht damit auseinandersetzt, wird das mit dem Einsatz nichts.
Einen ersten Einstieg bekommt man über die Dokumentation. Diese beschreibt die einzelnen Features aus technischer Sicht und ist insgesamt recht gut gelungen. Allerdings muss man berücksichtigen, dass sie aus historischen Gründen im Kontext von ASP.NET Core angesiedelt ist und sich auch inhaltlich häufig darauf bezieht. Und sie geht wenig auf konzeptionelle Dinge bzgl. des Designs der Microsoft Extensions ein; und schon gar nicht auf die Abgrenzung zum klassischen .NET Framework.
Aus diesem Grund werde ich es nicht bei diesem Beitrag bewenden lassen: Nachfolgende Beiträge werden einzelne Teilbereiche der Microsoft Extensions adressieren. Dabei werde ich mich insbesondere auf diese “Lücken” konzentrieren: Den Vergleich mit klassischen Funktionalitäten, Hinweise auf Konzepte und auf erweiterte Nutzung und Erfahrungswerte.
In diesem Sinne: Stay tuned!