© Excellent backgrounds/Shutterstock.com
Sauberer Projektstart - domänengetrieben mit Vaadin(ator)

Sauber starten


Aristoteles wusste: Der Anfang ist die Hälfte des Ganzen. Projekte können ihre Erfolgschancen erhöhen, wenn sie mit einer guten Struktur starten. Das gilt umso mehr dann, wenn die Technologie neu ist. Zentrale Fragestellung dabei ist, existierendes Wissen zu Klassenstruktur, Build, Testing und Frameworkeinsatz in ein Projekt zu tragen. Vaadinator ist ein Open-Source-Ansatz, der diese Fragestellung versucht zu beantworten.

Der Fokus von Vaadinator liegt auf Vaadin als UI-Technologie im JEE-Umfeld; die Prinzipien – vor allem das Generieren – sind universell anwendbar. Der erste von zwei Teilen der Artikelserie zeigt, wie mit Vaadinator die Basis für den gesamten Lebenszyklus einer Java-EE-Anwendung gelegt werden kann.

Wer das Webframework Vaadin [1], [2] noch nicht kennen sollte – Vaadin ist eine interessante Alternative zur Umsetzung einer Java-EE-Webanwendung mit einem komponentenbasierten (und dem Desktop nicht unähnlichen) Programmiermodell in „plain Java“. Wie bei allen Technologien gilt es auch bei Vaadin, eine gewisse Einstiegshürde zu überwinden. Wie hilfreich viele nicht offensichtliche Patterns und Vorgehensweisen sind, erschließt sich oft spät (zu spät) im Projekt. Entsprechend hilfreich wäre es also, einen Satz an Expertise aufzubereiten und in einem neuen Projekt damit zu starten. Je näher man dabei am Inhalt jenes Projekts ist, desto besser.

Die Zielsetzung von Vaadinator [3] ist genau das: einen schnellen – aber eben auch einen sauberen – Einstieg in Vaadin zu schaffen. Vaadinator verwendet dafür einen sehr kompakten und simplen domänen- und modellgetriebenen Ansatz. Aus Annotationen an einem Domänenobjekt (POJO; beispielsweise eine Adresse oder eine Bestellung) wird der Basiscode generiert, auf dem dann aufgebaut werden kann. Weil das Domänenobjekt individuell und projektspezifisch ist, kommt man dem Inhalt des Projekts nahe. Gleichzeitig ist die generierte Struktur nicht nur ein bequemer, sondern auch ein sauberer Weg: Patterns wie Model View Presenter (MVP [4]) lassen sich so von Beginn an etablieren.

Architektur wird damit zur gern (an)genommenen Dienstleistung über die Projektlaufzeit. Geht man beim Generieren über die reine Anwendungslogik hinaus und erstellt auch die Basis für Akzeptanztests, dann lässt sich der Lebenszyklus der Entwicklung proaktiv gestalten: Diese (nicht triviale) Aufgabenstellung rückt in greifbare Nähe, weil ein Startpunkt da ist.

Um Vaadinator (und die Prinzipien dahinter) näher zu erklären, verwenden wir ein simplifiziertes (aber realistisches) Beispiel. Ziel ist, die folgenden User Stories zu implementieren.

User Stories

Versetzen wir uns in die Welt der Onlineshops. Ein Kunde filtert die gewünschten Produkte aus dem Warenangebot heraus und legt diese zum späteren Erwerb in seinen elektronischen Warenkorb. Dieser soll bei jedem Aufruf eine Übersicht der gewählten Artikel, deren Einzelpreise und die Gesamtsumme des potenziellen Einkaufs anzeigen. Die darin enthaltende Mehrwertsteuer – gestaffelt nach 7 und 19 Prozent – ist ebenfalls auszuweisen.

Aus diesem Szenario entscheiden wir uns für die folgenden beiden User Stories als Inhalt einer ersten Iteration:

UC 1: Als Kunde möchte ich durch eine Übersicht von Produkten blättern, aus der ich (zum Zweck des späteren Kaufs) die Bezeichnung, eine kurze Beschreibung und den Bruttopreis entnehmen kann.

UC 2: Als Kunde möchte ich einen Artikel in den Warenkorb legen und mir im Anschluss meinen Warenkorb anzeigen lassen, aus dem

  • die Anzahl

  • die Artikelbezeichnung

  • der Nettopreis des Artikels

  • die Mehrwertsteuer (7 oder 19 Prozent) des Artikels

  • der Gesamtbruttopreis

  • die Summe der enthaltenen Mehrwertsteuer

hervorgeht. Ich möchte das tun, um mich mit einem guten Gefühl für die Bestellung zu entscheiden.

Umsetzung mit Vaadinator

Wie werden diese User Stories nun umgesetzt? Abbildung 1 fasst die Entwicklung mit Vaadinator zusammen: Am Anfang (Schritt 1) steht ein Domänenobjekt bzw. dessen Klasse (ein POJO mit Annotationen, hier „A“). Es wird (in Schritt 2) in ein Objektmodell (eine Art Cod...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang