Die Technologien ändern schneller und die Vielfalt nimmt zu. Muss man immer auf dem neusten Stand sein? Am Beispiel der Microsoft .NET Core Technologie im Zusammenspiel mit Angular werden konkrete Antworten für eine Webanwendung aufgezeigt.

Webanwendung Heute

Eine mögliche Architektur auf dem neusten Stand der Technik sieht wie folgt aus:

Benutzeroberfläche mit Angular 4
Geschäftslogik, Datenhaltung mit .NET Core 2
Einsatz eines Frameworks für den Datenbank-Zugriff, z.B. Dapper
Test der Schnittstellen zwischen Angular und .NET Core mit Postman
Vollständige Entkopplung zwischen Benutzeroberfläche und Logik

.NET Core ist open source und Plattform unabhängig (läuft z.B. auf Windows, Linux und Mac). Angular ist die am weitesten verbreitete Technologie für Benutzeroberflächen von Webanwendungen.

Der Lauf der Zeit

Vor 4-5 Jahren sah die Vorgänger-Architektur so aus:

Benutzeroberfläche mit Razor Views (Einsatz eines JavaScript-Frameworks wie jQuery)
Geschäftslogik, Datenhaltung mit ASP.NET MVC (Model View Control) 5
Einsatz eines Frameworks für den Datenbank-Zugriff, z.B. Dapper
Vollständige Entkopplung zwischen Benutzeroberfläche und Logik

Im Jahr 2013/2014 gab es Angular 1 bereits, steckte noch in den Kinderschuhen. Ab 2015 war AngularJS verfügbar. D.h. vor 4-5 Jahren war Angular im Zusammenspiel mit ASP.NET MVC kein Thema.

Muss es immer das (Aller)Neuste sein?

Diese Frage hängt von der Konstellation ab:

1) Entwicklung einer neuen Anwendung

Hier lohnt sich der Einsatz der neusten Technologien. Damit wird die Zeit bis zum nächsten Wechsel maximal verzögert. Zu beachten sind folgende Punkte:

Technologie / eingesetzte Version muss stabil sein
Es müssen auf Fremdprodukte vorhanden sein. Konkretes Beispiel: NHibernate war Anfang 2018 nicht für .NET Core 2 verfügbar.
Neben der Entwicklung muss auch das Hosting angeschaut werden. .NET Core ist viel komplizierter als ASP.NET MVC

2) Weiterentwicklung einer bestehenden Anwendung

Meist werden noch andere Fremdprodukte / Bibliotheken eingesetzt. Solange der Support für diese Produkte und Technologien gewährleistet ist, muss nicht auf die neuste Technologie gewechselt werden. Dies ist meist für einige Jahre gewährleistet. Ausser es gibt neue Funktionen, die von der Anwendung gebraucht werden.

Technologie Wechsel

In unserem Beispiel betrifft der Wechsel zwei Technologien:

1) Razor Views -> Angular

Es sind komplett verschiedene Technologien. Der bestehende Code kann nicht verwendete werden. Die Benutzeroberfläche muss neu entwickelt werden. Das bedeutet meistens viel Aufwand.

2) ASP.NET MVC -> .NET Core

Das Grundkonzept der Controller (Ablauflogik) kann übernommen werden. Der Startup-Code und die Konfiguration sind verschieden. Ein Teil des bestehenden Codes kann verwendet werden.

Im Normalfall ist der Controller-Teil eher klein. Darum ist es nicht so wichtig, wie viel davon wiederverwendet werden kann.

Wichtig ist, dass die Geschäftslogik nicht im Controller integriert ist.

Fazit

Wird eine Anwendung neu entwickelt, lohnt sich der Einsatz der neusten Technologien. Es sollen stabile Versionen eingesetzt werden. Weiter muss geprüft werden, ob es die nötigen Fremdprodukte zu dieser Technologie gibt.
Bei einer bestehenden Anwendung gibt es keinen zeitlichen Druck, die neusten Technologien einzusetzen.
Bei einem Technologiewechsel muss meist die Benutzeroberfläche neu entwickelt werden. Das ist mit viel Aufwand verbunden.
Die Geschäftslogik MUSS technologie-neutral sein. In unserem Fall: Programmierung in C# ohne Verweise / Referenzen auf Angular oder spezifische .NET Core Bibliotheken. Auf diese Weise kann die Geschäftslogik mit jeder Technologie eingesetzt werden, auch für ein App.

Links

Die 3 Kernbereiche Architektur, Schnittstellen und Fremdprodukte werden detaillierter untersucht. Als Grundlage dient der Überblick.

Dieser Teil ist Technik lastig und setzt Programmierkenntnisse voraus.

Geschäftslogik

Die Geschäftslogik muss in sich gekapselt sein. Dies bedeutet, dass sie nicht weiss, wie die Daten gespeichert werden. Sie weiss nur, dass es eine interne Schnittstelle zur Speicherung gibt. Wie die konkrete Umsetzung aussieht (File, Datenbank), darf die Geschäftslogik nicht wissen. Somit kann auf einfache Weise eine Oracle-Datenbank durch eine mySQL-Datenbank ersetzt werden.

Die Geschäftslogik darf auch nicht wissen, ob sie von einer Webanwendung oder einer Mobile App verwendet wird. Oder ob es beides miteinander gibt. Ist diese Trennung garantiert, kann die Benutzeroberfläche ausgetauscht oder es können neue Benutzeroberflächen hinzugefügt werden.

Diese Abhängigkeiten können einfach geprüft werden: Gibt es einen technischen Verweis (Import) zur Datenhaltung oder Benutzeroberfläche? Falls ja, gibt es ein Problem.

Datenhaltung

Die Datenhaltung kümmert sich nur um das Speichern, Suchen und Lesen von Daten. Je nach Anwendung können folgende Punkte wichtig sein:

Schnelle Suche von Daten in grossen Tabellen oder in mehreren Tabellen (sog. Joins)
Schnelle Speicherung von mehreren tausend Datensätzen auf einmal (sog. Bulk Insert)

Es ist möglich, dass die Geschäftslogik (teilweise) in der Datenbank in Form von Stored Procedures vorhanden ist. Aus Sicht der Wiederverwendbarkeit und des einfacheren Verständnisses bevorzugt der Autor eine Lösung im Programmcode (Java, C#).

Benutzeroberfläche

Jede Art der Benutzeroberfläche hat ihre Eigenheiten. Gemeinsam ist, dass es für jede Art Fremdprodukte gibt, welche die Entwicklungszeit verkürzen und die Qualität steigern. Wenn es sich nicht um eine ganz einfache Benutzeroberfläche handelt, sollte ein Fremdprodukt eingesetzt werden. Sonst wird das Rad nochmals erfunden.

Je nach eingesetztem Fremdprodukt drängt sich eine gewisse technische Struktur auf. Es ist wichtig, diese Struktur festzulegen und einzuhalten. Bei einer Webanwendung mit Angular ist eine Unterteilung in Module, Komponenten, Modelle und Services zwingend. Sonst ist der Code schwer verständlich und kaum erweiterbar.

Schnittstellen

Folgende Punkte sind zu beachten:

Versionierung: Im Lauf der Zeit gibt es Erweiterungen der Schnittstelle. Jede Erweiterung kann zu Inkompatibilitäten bei den Benutzern (meist andere Programme) führen. Ändert die Datenstruktur, weil es z.B. zusätzliche Daten gibt oder bestehende Daten wegfallen, hat das Auswirkungen bei den Benutzern. Deshalb ist eine Versionierung der Schnittstelle wichtig: Mehrere Versionen werden gleichzeitig unterstützt. So entscheiden die Benutzer selber, wann sie die neue Version verwenden. Ohne Versionierung müssen alle Benutzer gleichzeitig wechseln.
Robustheit / Fehlertoleranz: Beim Bezug von Daten muss damit gerechnet werden, dass der Inhalt stark variieren kann. Manchmal gibt es Fehler und es werden nicht alle Daten geliefert. Wichtig ist, dass versucht wird, möglichst alle Daten heraus zu bekommen. Fehler sollen möglichst genau dem Benutzer gemeldet und in ein Logfile geschrieben werden.
Kapselung: Bei Problemen mit der Schnittstelle darf nicht die gesamte Anwendung betroffen sein (und nicht mehr funktionieren). Die Datenstruktur der Schnittstelle darf z.B. in der Geschäftslogik nicht bekannt sein. Sonst führen Anpassungen in der Datenstruktur auch zu Anpassungen in der Geschäftslogik. Daten und Methoden der Schnittstelle müssen gekapselt sein.

Komplexe Fremdprodukte

Die einfachen Fremdprodukte werden nicht analysiert, weil diese zu wenig wichtig sind.

Wird ein Fremdprodukt an vielen Stellen in der Anwendung eingesetzt, macht eine Kapselung Sinn. Das kann z.B. ein eigenes Modul fürs Lesen und Erstellen von Excel-Files sein. Innerhalb dieses Moduls wird das Fremdprodukt eingesetzt. Anpassungen (z.B. neue Version) beschränken sich nur auf das eine Modul. Das Fremdprodukt kann auf diese Weise einfacher ausgewechselt werden.

Zusammenfassung

Je nach Komplexität der Anwendung dauert die detaillierte Analyse 1-3 Wochen. Das Resultat sind konkrete Aussagen, was gut ist und was verbessert werden soll. Die Verbesserungsvorschläge beinhalten eine grobe Aufwandschätzung. Das ist für die Planung und das weitere Vorgehen wichtig.

Schlagwort: Benutzeroberfläche

Rasanter Technologiewandel – .NET Core mit Angular