5. Fazit

Wir haben die folgende Client/Server-Anwendung entwickelt:

Um zur endgültigen Version des Codes zu gelangen, mussten wir viele Aspekte der Frameworks AngularJS und Spring 4 erläutern. Dieses Dokument kann daher dazu dienen, den Umgang mit diesen beiden Frameworks zu erlernen. In Abschnitt 1.3 wird erklärt, wo der Code zu finden ist und wie man ihn verwendet.

Wir haben gezeigt, dass die Client/Server-Anwendung in verschiedenen Umgebungen einsetzbar ist:

• als herkömmliche Webanwendung;
• als ausführbare Binärdatei auf Android-Emulatoren;

Auch dieses Tutorial behandelt die beiden Frameworks nicht erschöpfend. Für Angular müssten wir sicherlich auch die dazugehörigen Testtools behandeln. Das Testen ist ein wesentlicher Schritt beim Schreiben einer Anwendung. Die mit Angular verbundenen Tools ermöglichen es, diese Tests zu automatisieren und in einen Continuous-Integration-Prozess einzubinden.

Aus dieser Arbeit nehme ich zwei wichtige Punkte mit:

• Das Schreiben des Spring-Webdienstes war mäßig kompliziert. Von Anfang an war ich mit den Konzepten von Spring vertraut. Schwierigkeiten hatte ich lediglich bei der Absicherung des Webdienstes und später bei der Verwaltung von CORS-HTTP-Headern – zwei Bereiche, mit denen ich nicht vertraut war;
• Das Schreiben des Angular-Clients war aus mehreren Gründen wesentlich komplexer:
  • Mir fehlten ausreichende Kenntnisse der Programmiersprache JavaScript und ihrer Möglichkeiten;
  • Ich hatte Schwierigkeiten zu verstehen, wie asynchrone Programmierung im Browser funktioniert. Ich stellte mir das wie auf einem Server vor, wo diese Asynchronität durch die gleichzeitige Nutzung mehrerer Threads erreicht wird. Im Browser gibt es nur einen Thread, und asynchrone Aufgaben werden sequenziell statt parallel verarbeitet. Genauer gesagt können asynchrone Aufgaben zwar parallel laufen (zum Beispiel mehrere HTTP-Anfragen), aber die Ereignisse, die sie nach ihrer Ausführung auslösen, werden sequenziell verarbeitet. Es gibt daher keine parallele Ausführung, die verwaltet werden muss, und auch nicht die vielen Probleme, die damit einhergehen;
  • Angular ist ein umfangreiches Framework mit vielen Konzepten (MVC, Direktiven, Dienste, Model-Scope usw.). Es dauert lange, sich darin einzuarbeiten;
  • Angular schreibt keine bestimmte Entwicklungsmethode vor. Um dasselbe Ergebnis zu erzielen, kann man daher verschiedene Architekturen verwenden. Das ist verwirrend. Ich fühle mich wohler mit geschlossenen Frameworks, bei denen alle die gleichen Entwurfsmuster verwenden. Ich habe daher stets versucht, die Entwurfsmuster, die ich auf der Serverseite verwende, zu replizieren. Ich bin mit dem Ergebnis zufrieden, da ich glaube, dass es reproduzierbar ist. Das ist genau das, wonach ich gesucht habe. Ich habe jedoch keine Ahnung, ob ich von den „Best Practices“ von Angular abgewichen bin oder nicht;

Serge Tahé, Juli 2014.