In diesem Artikel beschreiben wir die Erfahrungen unseres .NET-Teams auf der Entdeckungsreise durch die neue Welt der Single Page Applications (SPA) mit JavaScript. Gesammelt haben wir diese Erfahrungen während der Neuimplementierung einer gewachsenen Kernanwendung zur Verwaltung von Produktstammdaten. Das Altsystem auf Basis von ASP.NET und Oracle PL/SQL ist den sich häufenden Änderungsanforderungen nicht mehr gewachsen und wird nach und nach abgelöst. Anwender des Systems sind rund 1 000 firmeninterne Mitarbeiter, die weltweit verteilt einen sprunghaft wachsenden Produktstamm von mehr als 500 000 Artikeln bearbeiten.

Der Arbeitsablauf der Anwender wird in unserer Neuimplementierung durch ein taskbasiertes Workflowsystem unterstützt. Abbildung 1 zeigt einen exemplarischen Screenshot.

Auf unserer Reise durch die neue Technologiewelt mussten wir uns an mancher Kreuzung für einen Weg entscheiden, nur um dann später festzustellen, dass wir doch im Kreis gelaufen sind. Es gab dunkle Schluchten, die durchschritten werden mussten, und Punkte mit herrlicher Aussicht. Damit Teams in einer ähnlichen Situation die Reise besser vorbereiten können, folgt hier unser Reisebericht.

Projektkontext und Kernanforderungen

Wir standen vor einer Situation, wie sie jeder von uns kennt: Ein Projekt steht vor einer Neuausrichtung und es stellt sich die Frage, auf welches Pferd, respektive, welche Technologie man zum gegebenen Zeitpunkt am besten setzen soll. In diesem Fall ging es besonders um die Clienttechnologie, die im Zuge der Durchdringung von mobilen Endgeräten und Trends wie HTML5 massiv in Bewegung ist.

In einer frühen Phase des Projekts hatte unser Entwicklerteam einen attraktiven Prototyp auf Basis von Microsoft Silverlight entwickelt. Damit konnten erfolgreich komplexe Anforderungen an der Oberfläche umgesetzt werden, wie zum Beispiel die asynchrone, clientseitige Auswertung von komplexen Regelprüfungen oder die visuelle Unterstützung beim Vergleich und Zusammenführen von Artikeln. Der Schwerpunkt unseres Teams lag damals auf der Entwicklung von Lösungen mit Microsoft .NET. Vor diesem Hintergrund haben wir uns für Silverlight entschieden und den Prototyp mit einer relativ steilen Lernkurve entwickeln können.

Am Ende der Prototyping-Phase waren wir also recht zufrieden. Doch wie das Leben in IT-Projekten so spielt, hatte Microsoft andere Pläne. Im Sommer 2012 gab Microsoft eine veränderte Clientstrategie bekannt, in der Silverlight nicht mehr vorkam. Als Architekt kommt man dann schnell in Argumentationsnöte, wenn man für ein strategisch wichtiges Projekt eine Technologie ausgewählt hat, die in der Presse [1] für tot erklärt wird.

Die Entscheidung für Silverlight als Clienttechnologie wurde also noch einmal auf den Prüfstand gestellt. Mittlerweile war auch klar, dass das Altsystem nicht in einem Schritt abgelöst werden kann und die neue Lösung sich daher gut in die vorhandene Webapplikationslandschaft integrieren lassen sollte. Dies führte im Herbst 2012 schließlich zu der Entscheidung für einen Webclient. Stellte sich nur die Frage nach der passenden Technologie.

Microsoft stellt mit ASP.NET MVC zwar ein Framework für die Serverseite zur Verfügung, lässt die Client­implementierung jedoch weitgehend offen. Der Begriff der Single Page Application ist nach AJAX, jQuery und Co der letzte Schrei (Kasten: „Single Page Application“).

Eine Untersuchung des unübersichtlichen Markts der wie Pilze aus dem Boden schießenden SPA-Frameworks ergab, dass zwei grundsätzliche Ansätze konkurrieren: Auf der einen Seite stehen jene, die den All-inclusive-Ansatz verfolgen und von Architekturvorgaben bis zur Deployment-Unterstützung alles mitliefern. Auf der anderen Seite steht der Best-of-Breed-Ansatz. Hier muss sich der Architekt für jeden Aspekt seiner SPA das jeweils am besten passende Framework aussuchen.

Die Untersuchung engte die Auswahl auf Sencha Ext JS als Vertreter des All-inclusive-Ansatzes und Ember als zentrales MVC-Framework eines Best-of-Breed-Ansatzes ein. Obwohl ein erster Durchstich mit Ext JS vielversprechende Funktionen darstellen konnte, gaben die Zweifel an deren Erweiterbarkeit bzw. an der Integrationsfähigkeit zusätzlicher JavaScript-Komponenten den Ausschlag für die Entscheidung zu einem Best-of-Breed-Ansatz. In der Folge beschreiben wir, mit welchen Komponenten wir diesen Ansatz ausgestaltet haben und welche Erfahrungen wir nach den ersten drei Monaten Entwicklung gemacht haben.

Vorgehensweise bei der Zusammenstellung unseres „SPA-Stacks“

In diesem Abschnitt stellen wir unseren JavaScript-Baukasten vor. Wir sind der Ansicht, dass er Softwarearchitekten und Entscheidern beim Aufbau einer eigenen Architektur weiterhelfen kann.

Doch bevor wir unser Design vorstellen, sei erwähnt, dass wir zum Zeitpunkt des Schreibens Ember in der Version 1.0 RC 3 verwenden. Ember Data (autarke Bibliothek, um Daten aus einer Persistenzschicht zu laden und zu ändern) ist derzeit nicht für den produktiven Einsatz geeignet [2] und kam daher bei der Zusammenstellung des Stacks nicht in Frage. Da wir uns für den Best-of-Breed-Ansatz, Ember, entschieden haben, mussten weitere grundlegende Konzepte und Softwarebausteine definiert werden.

Trotz oder gerade wegen des vielen JavaScripts wollten wir nicht auf bewährte Entwicklungsmuster und -vorgehen verzichten, wie wir sie aus anderen objektorientierten Programmiersprachen kennen. Die Unternehmenssoftware sollte erweiterbar, robust und gut zu warten sein. Insbesondere bei der Codequalität wollten wir so wenige Abstriche wie möglich von der .NET-Welt machen. So wollten wir beispielsweise nicht auf Unit Testing und Codemetriken verzichten.

Mit diesen Gedanken im Hinterkopf haben wir funktionale Bausteine gebildet, die wir unbedingt in unserem Design verwenden wollten. Parallel dazu haben wir den stark florierenden JavaScript-Markt beobachtet, um herauszufinden, was zurzeit technisch möglich ist und welche JS-Bibliotheken am populärsten sind. Frei nach dem Motto „Was viele andere verwenden, kann so schlecht nicht sein.“ Anschließend haben wir für jeden Baustein passende JS-Bibliotheken ausgesucht und in unseren Stack integriert. Herausgekommen ist folgender „SPA-Stack“ aus Abbildung 2.

User Interface

Styling

Keine Webapplikation kommt ohne Cascading Style Sheets (CSS) aus. Wir wollten jedoch von Beginn an CSS nicht nativ verwenden, sondern auf einen Preprocessor setzen, um einfacher und eleganter Gestaltungsvorlagen zu erstellen. Die beiden Platzhirsche sind Sass [3] und LESS [4]. Trotz marginaler Unterschiede haben wir uns für LESS entschieden. Wer mehr über die Unterschiede erfahren möchte, der findet von Chris Coyier eine ausführliche Erläuterung [5]. Um das Ramp-up zu begünstigen, setzen wir auf Bootstrap; eine von Twitter entwickelte Bibliothek zur Gestaltung von Webseiten. Diese enthält neben soliden Gestaltungsvorlagen auch spezielle Steuerelemente auf Basis von JavaScript. Dessen CSS-Definitionen dienen als gutes Fundament und lassen sich problemlos erweitern.

Templating

Die verschiedenen Sichten zerfallen in wiederverwendbare HTML-Brocken. So kann es beispielsweise eine HTML-Repräsentation eines Kunden oder Auftrags geben. Diese Brocken lassen sich in unterschiedlichen Stellen der Applikation integrieren. Don’t Repeat Yourself (DRY)! Darüber hinaus bedarf es einer Templatesprache, um die HTML-Repräsentation semantisch zu beschreiben. Wer Ember sagt, muss auch Handlebars sagen! Handlebars [6] ist eine Templatesprache. Zusammen mit Ember hat man ein ausgereiftes Template­system.

UI Controls

Auch hier war uns von Beginn an klar, dass die Standard-HTML-Elemente nicht ausreichen würden. Mit HTML5 sind zwar einige Controls bzw. Input Types, wie z. B. der Typ date, dazugekommen, jedoch variiert deren Unterstützung mit jedem Browser. Eigene Controls zu erstellen, ist teuer. Und warum sollte man das Rad neu erfinden wollen? Am liebsten wollten wir hier eine UI-Bibliothek verwenden, die relativ schlank und einfach zu bedienen ist...