Wer heutzutage mit der Entwicklung einer Web-Anwendung beginnen möchte, hat die Qual der Wahl: Dutzende teils diametral entgegengesetzte Konzepte und viele verschiedene Frameworks wollen ausprobiert und gegeneinander abgewogen werden. Doch irgendwann kommt der Punkt, an dem es eine Entscheidung zu treffen gilt. Wenn es aber nicht um einen softwaretechnischen Versuchsballon, sondern um eine reale Anwendung im Enterprise-Umfeld geht, ist diese Entscheidung gerade für Microsoftaffine im Moment nicht so einfach.
ASP.NET 5 bringt viele Änderungen
Die in Q1 2016 anstehende Veröffentlichung von ASP.NET 5 bringt nicht nur ein paar kosmetische Verbesserungen. Es werden in großem Stil alte Zöpfe abgeschnitten. Der bekannte .NET-Entwickler und Autor Stephen Walter schreibt hierzu in seinem Blog:
Drei der größten Änderungen sind:
- ASP.NET WebForms ist tot. Es wird in Zukunft nur noch ASP.NET MVC geben
- ASP.NET MVC, Web API und SignalR verschmelzen zu einer Plattform (ASP.NET MVC 6)
- ASP.NET Hosting wird künftig auch auf Maschinen mit Linux und OS X möglich sein.?
Zum Zeitpunkt der Veröffentlichung dieses Beitrags befindet sich ASP.NET 5 noch in der Beta-Phase, dürfte aber inzwischen im Wesentlichen „feature complete" sein. Der erste Release Candidate (RC1) ist für November 2015 angekündigt und soll noch einige Stabilisierungen bringen.
Nun könnte man argumentieren, dass der Reifegrad fortgeschritten genug ist, um eine neue Software gleich auf der neuen Plattform zu entwickeln. Die Vorteile liegen auf der Hand:
- Die beteiligten Entwickler eignen sich Kenntnisse zu aktuellen Technologien an, mit denen sie sich in den meisten Fällen früher oder später ohnehin beschäftigen werden müssen.
- Die Software bekommt einen modernen Unterbau anstatt auf veraltete Technik aufzusetzen
- Etwaige Migrationsaufwände reduzieren sich in den kommenden Jahren erheblich.
Warum es oft noch etwas dauern wird
Was könnte also dagegen sprechen? Zum einen ist der produktive Einsatz von Vorabversionen im Enterprise-Umfeld vielfach nicht möglich. Software-Hersteller sichern sich für diesen Fall üblicherweise mit Ausschlussklauseln oder gar mit Verboten ab. Anderseits nimmt die Entwicklung von Enterprise-Software in der Regel einige Zeit in Anspruch, sodass im Moment der Produktivnahme wahrscheinlich keine Beta-Version mehr zum Einsatz kommen muss. Es könnten aber Zusatzaufwände entstehen, falls es zwischen dem RC1 und der finalen Version in einzelnen Bereichen noch Änderungen geben sollte. Auch wenn diese Änderungen in den meisten Fällen überschaubar bis nicht vorhanden sind, ist das ein weiterer Konjunktiv, der die Verwendung einer vom Hersteller noch nicht freigegebenen Version schwierig macht.
Im konkreten Fall von ASP.NET 5 gibt es außerdem eine weitere Randbedingung: Die gewohnte Tool-Unterstützung setzt Visual Studio 2015 voraus, es müssen also entsprechende Lizenzen vorhanden sein. Aufgrund der zahlreichen Änderungen gegenüber der Vorgängerversion ist die Unterstützung älterer Versionen von Visual Studio äußerst fraglich. Der plattformübergreifende Ansatz von ASP.NET 5 bringt es zwar mit sich, dass in Zukunft häufiger als bisher alternative Entwicklungsumgebungen (z. B der Atom-Texteditor mit OmniSharp) zum Einsatz kommen werden. Im Enterprise-Bereich ist Visual Studio für die Microsoft-Plattform aber so gut wie immer gesetzt.
Welche Optionen hat man also, wenn sich der Pre-Release-Status von ASP.NET 5, die Abhängigkeit von der 2015er-Version von Visual Studio oder etwas anderes als Showstopper erweist? Auch wenn es im Einzelfall auf die jeweiligen Randbedingungen ankommt, halte ich es für zu kurzsichtig, die Situation im Vorfeld der neuen Version von ASP.NET einfach auszublenden und stur auf ASP.NET 4 bzw. ASP.NET MVC 5 zu setzen. Die Evolution der Web-Entwicklung schreitet in rasantem Tempo voran und macht vor der Software, die man heute entwickelt, nicht Halt. Auf Technologien zu setzen, die zum Zeitpunkt des Projektstarts bereits überholt sind, führt absehbar dazu, dass die Entwickler sich mit den Problemen von gestern beschäftigen müssen, anstatt die Herausforderungen von morgen zu meistern. Auf Dauer wird eine solche Konstellation auch und vor allem eines sein, nämlich ein erheblicher Kostentreiber.
Mögliche Lösungen
Es gibt verschiedene Wege aus diesem Dilemma. Ein Weg könnte darin bestehen, verstärkt auf JavaScript-Frameworks zu setzen und den Migrationsaufwand dadurch überschaubar zu halten, dass man ASP.NET MVC quasi nur noch als Hosting-Plattform verwendet. Die Auswahl der geeigneten JavaScript-Frameworks ist aber keineswegs trivial. Hierbei gibt es Kriterien zu berücksichtigen wie den Reifegrad eines Frameworks, die Unterstützung verschiedener Browser und Gerätetypen, die Qualität der Dokumentation, die Abhängigkeit oder Unabhängigkeit von bestimmten Herstellern, die Möglichkeit kommerziellen Supports usw. Vor allem sind aber die JavaScript-Frameworks, in eher noch höherem Maße als ASP.NET, den turbulenten Entwicklungen im Web-Umfeld ausgesetzt. Auch bei den aktuell populärsten Frameworks kann man bestenfalls erahnen, ob diese in zwei Jahren noch regelmäßig aktualisiert und verbessert werden. Ein Beispiel aus der jüngeren Vergangenheit ist AngularJS, das sich schon fast zum Quasi-Standard für Single-Page Applications entwickelt hatte, bevor dieser Zustand beinahe über Nacht mit einem großen Fragezeichen versehen wurde, als zahlreiche nicht-rückwärtskompatible Änderungen für die nächste Version angekündigt wurden.
Enterprise-Anwendungen werden fast immer über einen Zeitraum von mehreren Jahren betrieben, manchmal sogar deutlich über die ursprünglich geplante Lebensdauer hinaus. Deswegen gelten für Enterprise-Anwendungen höhere Ansprüche in Sachen Stabilität und Kontinuität, als für die volatilen Web-Plattformen, in deren Umfeld die meisten JavaScript-Frameworks entstanden sind. Entscheidend ist zum einen die Konzeption einer für den Einsatzzweck optimal geeigneten Software-Architektur. Zum anderen sind die zu verwendenden Technologien und Frameworks mit Bedacht auszuwählen und zwar so, dass man sich von einzelnen Komponenten bei Bedarf auch wieder trennen kann. Das entspricht im Grunde dem Prinzip der losen Kopplung, einem in der Software-Entwicklung seit Langem bewährten Entwurfsmuster.
Übertragen auf die aktuelle Situation im ASP.NET-Umfeld bedeutet das, dass man in den nächsten Monaten am meisten davon hat, wenn man seine Schwerpunkte in Bereichen setzt, die von den Neuerungen durch ASP.NET 5 wenig bis gar nicht betroffen sind. Für die Projektplanung kann das bedeuten, dass man reine Frontend-Features und reine Backend-Features tendenziell vorziehen sollte und Themen, die sich durch mehrere Bereiche ziehen (cross-cutting concerns), tendenziell eher nach hinten schieben sollte. Dann ist man in der Lage, ein heute auf der Basis von ASP.NET 4 begonnenes Projekt ohne große Migrationsaufwände auf Basis von ASP.NET 5 fortzusetzen.