Kommentar: ASP.NET vNext – hoher Reifegrad mit kleinem Makel
ASP.NET Next bringt Performance und Flexibität. Dies geht allerdings mit Breaking Changes und einer weiteren Segmentierung von .NET einher.
- Manfred Steyer
Die diese Woche auf der TechEd North America angekündigten Neuerungen rund um die nächste Version von ASP.NET lassen sich vor allem in zwei Gruppen aufteilen: Performance und Flexibilität.
Performance erreicht das Produktteam durch den Einsatz einer für Serveranwendungen optimierten .NET-Version, die lediglich ausgewählte, für Serveranwendungen relevante Bibliotheken enthält. Dazu kommt die Möglichkeit, nur noch jene Funktionen zu laden, die die jeweilige Webanwendung benötigt. Dank der neuen Compiler-Plattform Roslyn ist nach einer Änderung auch nicht mehr das gesamte Projekt neu zu kompilieren. Das führt nicht nur zum rascheren Start der Anwendung, sondern erleichtert Entwicklern auch das Leben, da diese Änderungen ohne Zeitverzögerung testen können.
Somit schaut sich ASP.NET Vorzüge von Techniken wie dem eventgetriebenen, nicht blockierenden I/O-JavaScript-Framework Node.js ab, ohne jedoch eigene Vorzüge wie Typisierung oder bewährte Frameworks aufgeben zu müssen. Hieran sieht man wieder einmal, dass Konkurrenz das Geschäft belebt.
Flexibler wird ASP.NET vNext, indem Microsoft es von der Komponente System.Web und somit von IIS entkoppelt sowie von Grund auf als Open-Source-Projekt gestaltet. Somit lassen sich die betroffenen Teile einfacher auf andere Plattformen portieren. Im Zuge dessen vereinheitlicht Microsoft auch die teilweise ähnlichen Frameworks ASP.NET MVC, ASP.NET Web API und ASP.NET Web Pages.
Der kleine Makel
Dass das alles nicht ohne "Breaking Changes" möglich ist, liegt auf der Hand. Im Fall von System.Web ist dies auch verständlich, zumal diese Komponente, die es seit ASP.NET 1.0 gibt, stark mit Web Forms, MVC aber auch mit IIS verwebt ist. Die Vereinheitlichung von MVC und Web API sowie die damit einhergehenden grundlegenden Änderungen wären jedoch zu vermeiden gewesen. Leider hat Microsoft hier bei der Entwicklung der ASP.NET Web API grundlegende Prinzipien des Softwareentwurfs sowie Rückmeldungen von Experten außer Acht gelassen, indem die Entwickler Konzepte aus der MVC-Welt (Model View Controller) leicht verändert nachgebaut haben. Auf diese Weise wurden Code-Redundanzen geschaffen, die es nun zu beseitigen gilt.
Dass voraussichtlich Web Forms, ASP.NET AJAX und die WCF-Integration (Windows Communication Foundation) aufgrund ihrer starken Koppelung zu System.Web in der neuen Welt keinen Platz haben, ist bemerkenswert. Im Fall der letzten beiden Techniken zeigt das einmal mehr, dass die Fackel hier an ASP.NET Web API übergegangen ist.
Good News, Bad News
Die gute Nachricht lautet, dass die aktuellen Versionen von MVC, Web API, Web Pages und Web Forms weiterhin unterstützt werden. Somit muss sich kein Entwickler gezwungen sehen, sich bei einem bestehenden Projekt auf diese Änderungen einzulassen. Dazu kommt leider, dass die voranschreitende Segmentierung von .NET das Potenzial hat, unter Entwicklern für Verwirrung zu sorgen und die Wiederverwendbarkeit von Quellcode trotz Vorhandensein der Portable Libraries einschränkt. Auf der anderen Seite ist die Notwendigkeit dieser Segmentierung auch nachvollziehbar, zumal eine Portierung des gesamten Frameworks, mit all seinen Typen, die sich in der letzten Dekade angesammelt haben, nicht realistisch ist.
Die Tatsache, dass sich die .NET-Welt den Luxus leisten kann, für die nächste Version ihres Web-Frameworks in erster Linie umfangreiche Refaktorierungsmaßnahmen vorzusehen, zeigt, dass es mittlerweile einen gewissen Reifegrad erreicht hat. Darüber hinaus führen diese Maßnahmen dazu, dass sich ASP.NET künftig mehr denn je auf Augenhöhe mit Konkurrenz-Techniken befindet und dass aufgebautes Wissen im .NET-Umfeld wertbeständig bleibt. (ane)
