Als wir anfingen uns mit XPages zu beschäftigen, waren wir sehr schnell begeistert von den neuen Möglichkeiten, moderne Web-Anwendungen auf Basis von IBM Lotus Notes und Domino zu entwickeln. Insbesondere hat uns gut gefallen, dass die Stärken von Lotus Notes und Domino, wie Sicherheit, Volltextsuche, Mail-Integration und viele mehr, kombiniert wurden mit einer auf JavaServer Faces basierenden Entwicklungsumgebung.
Relativ schnell wurde uns klar, was uns bei XPages fehlte: die Trennung zwischen der Business-Logik und der Oberfläche der Anwendung. Dieses Prinzip der Anwendungsentwicklung gewährleistet ein höhere Codequalität und eine bessere Wartbarkeit.
Unsere bisherigen auf LotusScript basierenden Notes-Client-Anwendungen waren schon nach diesem Paradigma entwickelt worden. Bei XPages die Business-Logik in einzelnen Feldern und Aktionen zu hinterlegen, kam uns wie ein Rückschritt vor.
Aus diesem Grund hatten wir uns entschieden, ein XPages-Framework nach dem Model View Controller-Pattern mit einer sauberen Trennung zwischen der Business-Logik und der Oberfläche zu entwickeln.
Das Model View Controller-Pattern ist so aufgebaut, dass die Business-Logik sich komplett im so genannten Model befindet. Die Oberfläche wird in der View realisiert. Die gesamte Interaktion zwischen dem Model und der View wird über den Controller gesteuert.
Der große Vorteil bei dieser Aufteilung besteht darin, dass das Model selber nichts von seiner Darstellung weiß. Wenn nun Änderungen an der Oberfläche vorgenommen werden, so muss an dem Code für die Business-Logik keine Anpassung vorgenommen werden. Somit wird die Gefahr verringert, dass unbeabsichtigt bereits funktionierender Code fehlerhaft wird. Weil die View mittels des Controllers nur über wohl definierte Schnittstellen auf das Model zugreifen kann, wird im Umkehrschluss das Risiko von Seiteneffekten minimiert, wenn es Anpassungen an der Business-Logik gibt.
Dieses Prinzip des Anwendungsaufbaus setzen wir bereits seit 2006 erfolgreich bei unseren klassischen Notes-Anwendungen ein. Wer einmal einen genaueren Blick darauf werfen möchte, kann bei OpenNTF fündig werden, Unser Framework steht dort unter der Apache-Lizenz als assono Framework 2 als Open Source zur Verfügung.
Das Model View Controller-Pattern auf XPages angewendet hat folgenden Aufbau.
Bei der Implementierung unseres XPages-Frameworks haben wir uns entschieden, Java den Verzug gegenüber Server Side JavaScript zu geben. Die Model- und die Controller-Klassen sind somit komplett objektorientiert in Java geschrieben.
Welche Vorteile ergeben sich aus diesem Aufbau? Aus unserer Sicht sind es eine ganze Menge!
Die Business-Logik in den Model-Klassen kann unabhängig von der eigentlichen XPage entwickelt und getestet werden. Somit können für die Model-Klassen automatisierte Tests, z.B. für JUnit, geschrieben werden. Außerdem kann parallel von mehreren Entwicklern sowohl an der Business-Logik als auch an der Oberfläche geschrieben werden. Neben dem Zeitvorteil ist dabei auch entscheidend, dass Entwickler mit unterschiedlichen Erfahrungen und Wissensständen in HTML, CSS, JavaScript und Java eingesetzt werden können. So kann ein Entwickler mit mehr Erfahrungen in der Web-Programmierung die eigentliche XPage entwickeln, während ein anderer Entwickler mit LotusScript-Hintergrund sich leichter in der Java-Welt zurechtfindet.
Auch das ist ein Vorteil des Framework-Ansatzes: Das Framework kümmert sich um die Interaktion zwischen Model-Klasse und der XPage. Der Entwickler definiert lediglich, welche Felder Pflichtfelder sind und der Controller sucht automatisch die zugehörigen Eingabeelemente heraus. Zusätzlich dazu werden auch automatisch alle korrespondierenden Label mit einer definierten CSS-Klasse versehen, so dass der Anwender alle Pflichtfelder als solche erkennen kann.
Ein weiterer Vorteil kommt mit der Zeit immer stärker zum Tragen, wenn an schon länger produktiven XPages-Anwendungen Anpassungen vorgenommen werden sollen: In unserem Framework befindet sich jeder Code, der Business-relevant ist, zentral in den Model-Klassen. Unabhängig davon wer ursprünglich die XPages-Anwendung entwickelt hat, der jetzt mit der Maintenance beauftragte Entwickler findet den entscheidenden Code an einer zentralen Stelle.
In folgenden Blog-Artikeln werden wir auf weitere Aspekte unseres XPages-Frameworks eingehen.
