Mittendrin.

Zurück

Flurfunk der eXperts.

Hier erfahren Sie mehr über eXperts, Technologien und das wahre Leben in der SDX.

Aktuelle ASP.NET-Entwicklung im Enterprise-Umfeld

11.11.201508:00 Uhr , Torben Graefe

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:

"ASP.NET 5 is the most significant new release of ASP.NET in the history of the ASP.NET framework — it has been rewritten from the ground up."

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.

6 Kommentare

11.11.20158:42 Uhr
Mark

Aus meiner Sicht hat ASP.NET 5 ein ganz anderes Problem… bei der Verwendung von .NET Core sind die meisten zur Verfügung stehenden .NET-Bibliotheken erst einmal außen vor. Sie stehen also nicht per NuGet bereit und können nicht verwendet werden. Es ist fraglich, wie schnell die Anbieter hier umsteigen werden und ob sie es technologisch überhaupt können. Das bedeutet, dass die Adaption der Plattform länger dauern wird und mit viel mehr Fragezeichen versehen ist.

Zu den Bedenken bzgl. JS-Frameworks: nicht auf eine moderne Technologie zu gehen können sich Unternehmen heutzutage immer weniger leisten. Auch große Enterprise-Unternehmen erkennen das immer mehr. Sicher nicht bei Intranet-LoB-Anwendungen, auf jeden Fall aber bei nach außen sichtbaren Applikationen. Hier muss viel schneller "das Neueste" adaptiert werden, um dem Kunden gegenüber technologisch auf dem aktuellsten Stand zu sein und ihm eine bestmögliche UX zu bieten. Und auch hin zu Angular 2 gibt es mittlerweile Migrationspfade, der Schmerz ist also verkraftbar. Generell ist zu sagen: die Webwelt wird dynamischer/volatiler und darauf muss man als Unternehmen und Entwickler reagieren, um nicht abgehängt zu werden. In einem festen starren Mindset zu verharren wäre fatal.

12.11.201511:28 Uhr
Torben Graefe

Danke für die Anmerkungen!

Nach meinem Kenntnisstand setzt ASP.NET 5 nicht zwingend die Verwendung von .NET Core voraus. Scott Guthrie schreibt dazu:

"If you don't want to have to update your app you can instead run ASP.NET 5 applications on the full .NET Framework (version 4.5.2 and above). When doing this you have access to the complete set of .NET Framework APIs. Your existing applications and libraries will work without modification on this runtime."

Quelle: http://weblogs.asp.net/scottgu/introducing-asp-net-5

Falls sich das inzwischen geändert haben sollte, habe ich die entsprechende Meldung verpasst.

Wenn ich Enterprise-Anwendungen schreibe, meine ich aus meiner Perspektive heraus in erster Linie "Intranet-LoB-Anwendungen". Dieser Begriff gefällt mir ausgesprochen gut und ich denke, ich sollte ihn ihn mir für zukünftige Beiträge zu dem Thema zu eigen zu machen.

Bei den nach außen sichtbaren Applikationen sollte man noch zwischen B2C und B2B unterscheiden. Die Aussage zur Attraktivität "des Neusten" kann ich für B2C so unterschreiben. Für B2B gelten aber u. U. ähnliche Voraussetzungen wie für die Intranet-LoB-Anwendungen, da in vielen Unternehmen immer noch ältere Versionen des Internet-Explorers im Einsatz sind.

12.11.201520:40 Uhr
Mark

Ich habe nicht geschrieben, dass ASP.NET 5 zwingend .NET Core voraussetzt, sondern dass sich bisherige .NET-Bibliotheken nicht verwenden lassen, *wenn* .NET Core verwendet wird. Natürlich muss man das nicht, aber das hat dann wiederum die Einschränkung, dass das Hosting unter Linux/MacOS nicht möglich ist und man wieder auf das volle (nicht-modulare) .NET angewiesen ist… diese Unterscheidung kommt im Beitrag übrigens zu kurz. Zumindest bin ich gespannt, wie sich .NET Core entwickeln wird, derzeit bin ich da noch skeptisch — das erinnert mich an das WinRT-App-Modell, was ja im Prinzip auch ein kastriertes WPF war… der Rest ist Geschichte.

Browser-Kompatibilität ist wohl die größte "Einschränkung" bei LoB-Anwendungen, doch auch kein Hexenwerk. Fakt ist: für einen Web-Stack muss man sich entscheiden und dass der in einem Jahr schon veraltet sein wird ist auch klar. Dennoch oder gerade deswegen sollte man aber nicht auf moderne JavaScript-Bibliotheken verzichten, wenn diese die Anforderungen erfüllen. Denn gut umgesetzt bietet eine solche Anwendung eine herausragende UX und auch wenn das vielleicht niemand explizit bestellt hat — daran messen Anwender *auch* die Qualität, denn das ist es, was sie sehen.

Nur weil eine JavaScript-Bibliothek in einem Jahr etwas älter ist, heißt das ja nicht, dass man sie direkt ersetzen muss oder die UI komplett neu zu bauen hat. Wenn dann in 10 Jahren eine Modernisierung ansteht, ist man natürlich gut beraten, wenn das Backend sauber entkoppelt ist, soviel ist klar. Und auch clientseitig sollte die *Kernlogik* unabhängig von einer Bibliothek sein. Aber sonstige Verrenkungen zu machen, nur um eine Bibliothek zu "kapseln", führt nur zu abstrusen Verkomplizierungen mit den einhergehenden Nachteilen (Aufwand, Wartbarkeit, Übersichtlichkeit, etc.)… und wofür? Am Ende wird eine Anwendung dann doch lieber neu entwickelt als bestimmte clientseitige Bestandteile einer Altanwendung zu übernehmen — dass so etwas passiert, habe ich in vielen Jahren Business-Anwendungen noch nie erlebt (weil es auch nicht funktioniert).

13.11.20159:23 Uhr
Torben Graefe

Ich bin in Bezug auf .NET Core auch skeptisch. Es dürfte sehr davon abhängen, was Microsoft in den nächsten 1-2 Jahren an Features ergänzt bzw. nachliefert. Für marktreif halte ich es zum jetzigen Zeitpunkt nicht, weswegen ich bei ASP.NET 5 den Weg mit dem "vollen" .NET-Framework gehen würde. Bei Unternehmen, die auf Microsoft als Plattform setzen, ist ja meist ohnehin eine windowszentrierte Infrastruktur vorhanden, sodass z. B, die neue Hostingoptionen eine eher untergeordnete Rolle spielen.

Es liegt mir fern, vom Einsatz moderner JavaScript-Bibliotheken abzuraten. Ich war bei uns sogar mit der erste, der JavaScript nicht nur zur Ergänzung eingesetzt hat. Allerdings habe ich in jüngerer Zeit mehrmals eine gewisse Leichtfertigkeit bei der Einbindung weiterer Frameworks beobachtet, die ich kritisiere. Wenn einem z. B. das Calender-Control von Angular Bootstrap UI nicht so gefällt, sollte man IMHO eher etwas Zeit hineinstecken, um es umzustylen, als nur für das Calender-Control zusätzlich das komplette AngularStrap einzubinden. So etwas wird zwar meistens gut gehen, muss es aber nicht. Ich hatte gerade erst das Problem, dass ein im Grunde unnötiges Framework eine Web-Applikation vorübergehend unbrauchbar gemacht hat, weil in der aktuellsten, über NuGet geholten Version unter bestimmten Umständen ein offenbar zu Debug-Zwecken gedachtes Statement mit einer Zeitmessung ausgeführt wurde, die in IE9 nicht funktioniert hat.

Ich bin auch kein Freund davon, JavaScript-Bibliotheken ohne triftigen Grund weiter zu kapseln. Selbst, wenn das für den Moment reibungslos funktioniert, kann das im Verlauf der Weiterentwicklung weitere Verrenkungen an Stellen nach sich ziehen, die sich ansonsten mit einfachsten Mitteln hätten lösen können. Updates mit etwaigen Bugfixes und Verbesserungen können u. U. nicht einfach übernommen werden, usw. So etwas erinnert mich immer ein wenig an das Branding von Betriebssystemen für Mobiltelefone. Da wartet man manchmal auch gut und gerne ein halbes Jahr auf ein vom Hersteller längst freigegebenes Update mit möglicherweise wichtigen Sicherheitsverbesserungen. Und wenn das Update dann nach mehrmaliger Verschiebung endlich da ist, hat man meisten mehr neue Probleme als erkennbaren Mehrwert.

13.11.201512:24 Uhr
Mark

Na dann sind wir uns ja einig… und ich hatte scheinbar (?) nur den initialen Beitrag falsch gelesen bzw. falsch gedeutet.

Einen Zoo an JavaScript-Bibliotheken aufzubauen halte ich auch für eine Todsünde… nicht nur macht man sich abhängig von der zusätzlichen Bibliothek (inkl. Weiterentwicklung, Support, Bugbehebung, etc.), sondern man bekommt auch schnell Versionskonflikte, wenn die Bibliothek weitere Basisbibliotheken (z.B. jQuery oder Angular) verwendet und diese aktualisiert werden. Das ufert zwangsläufig im Chaos aus. Von zusätzlichem Einarbeitungsaufwand für neue Entwickler ganz zu Schweigen. Die Komplexität auch aus dieser technologischen Sicht zu reduzieren, kann meiner Meinung nach nur gut sein…

Für unsere LoB-/Business-Anwendungen setzen wir hier auf professionelle Bibliotheken, u.a. Telerik mit Kendo UI. Features, Updates und Support sind so hochwertig, dass die Notwendigkeit weiterer Bibliotheken im UI-Segment größtenteils entfällt. Zudem ist unsere Produktivität damit stark gestiegen. Im Zusammenspiel mit Angular, Bootstrap und über Breeze mit ASP.NET Web API ein Traum. Kann es nur empfehlen.

13.11.201513:20 Uhr
Torben Graefe

Ich habe mir die entsprechenden Stellen in meinem Blog-Beitrag noch einmal durchgegangen und kann schon nachvollziehen, wenn jemand eine generelle JavaScript-Framework-Skepsis aus meinen Ausführungen herausliest. Falsch gelesen würde ich also nicht sagen, eher falsch gedeutet. Mir ging es in erster Linie darum, dass Software-Architektur und Framework-Auswahl auf den jeweiligen Einsatzzweck abzustimmen sind. Und dabei gibt es aus meiner Sicht mindestens zwei wesentliche Gesichtspunkte: 1. Frameworks sind nicht automatisch für jeden Einsatzzweck geeignet, nur weil sie gerade populär sind. 2. Eine bestimmte Kombination, die für ein Projekt optimal ist, ist dadurch nicht automatisch für ein zweites Projekt optimal.

Ein weiterer, noch unerwähnt gebliebener Aspekt ist das Vorwissen der Entwickler. Wenn mehrere Teammitglieder schon jahrelange Erfahrungen mit einem bestimmten Framework gesammelt haben, kann es sich günstig auf die Produktivität auswirken, wenn eben dieses Framework erneut zum Einsatz kommt, selbst wenn es für einen bestimmten Einsatzzweck nicht die erste Wahl darstellt. Die ersten Gehversuche mit neuen Paradigmen und Technologien sind immer die zeitaufwändigsten und fehleranfälligsten.

Ich möchte mich außerdem von einer JavaScript-Bibliothek wieder trennen können, falls diese nicht mehr weiterentwickelt wird oder im Laufe der Zeit Anforderungen hinzukommen, die sich mit einer anderen Bibliothek deutlich besser lösen lassen. Das natürlich nicht für die 2-4 primären Frameworks der Anwendung, wohl aber für ergänzende Frameworks, wie z. B. eine Komponente für die Darstellung von Geodaten. Da achte ich dann schon darauf, nicht zu viele Abhängigkeiten zu schaffen und verwende z. B. lieber eine Galerie-Komponente aus meinem Basis-GUI-Framework, um zwischen verschiedenen Ansichten zu wechseln, als irgendein "Blättern"-Feature, das fest im Geodaten-Framework integriert ist (fiktives Beispiel). Wenn das "Blättern"-Feature eine außerordentlich gute User Experience böte, wäre das natürlich noch etwas anderes.

Dein Kommentar wartet auf Freischaltung.

Artikel kommentieren

Zurück

Tag Cloud