Ports and Adapters – eine Architektur für moderne Applikationen

Anbieter zum Thema

MicroConsult Academy GmbH

emlix GmbH

Linutronix GmbH

Method Park Software AG

Houston, haben wir ein Problem?

Sind in unserem Salat-Beispiel die Probleme mehrheitlich ästhetischer Natur, so zeigen sich bei Anwendungen nach einem Schichtenmuster handfeste Probleme. Zunächst wollen wir die klassische Schichtenarchitektur betrachten. Sie besteht zumeist aus drei Schichten:

• Der Datenhaltungsschicht, die für die Speicherung der Anwendungsdaten zuständig ist,

• der Logikschicht, die das Herzstück der Anwendung darstellt,

• und zuletzt der Darstellungsschicht, zuständig dafür die Daten anzuzeigen und mit dem Benutzer zu interagieren.

Um die drei Teile der Anwendung nun koordiniert miteinander kommunizieren zu lassen, legt man meist fest, dass eine Schicht nur mit der unter ihr liegenden Schichten kommunizieren darf. In der Praxis werden jedoch häufig Geschäftslogik und Benutzeroberflächen-Code vermischt. Daraus resultieren folgende Hauptproblemfelder:

• Die Anwendung kann nicht ohne größeren Aufwand automatisiert getestet werden.

• Es ist knifflig, die Anwendung ganz oder in Teilen wiederzuverwenden beziehungsweise zu ersetzen.

• Die Entwicklung der einzelnen Anwendungskomponenten lässt sich nur schwer unabhängig voneinander vorantreiben.

Hinzu kommt, dass Anwendungen häufig stark an eine Datenbank, eine Darstellungsform (wie HTML) oder einen externen Service gekoppelt sind. Ändert sich das Datenbankschema oder muss die Datenbank gar durch eine andere ersetzt werden, können Entwickler in ihrer Arbeit blockiert werden und so unnötige Kosten entstehen.

Ein Beispiel aus der Praxis: Eine Anwendung des Kunden nutzte einen proprietären SQL-Datenbank-Server für die Datenhaltung. Für bestimmte Anwendungsfälle wurde die Funktionalität als sogenannte „Stored Procedures“, also in der Datenbank hinterlegten Funktionen, realisiert. Wann immer ein Benutzer gewisse Anwendungsfälle durchführen wollte, rief er von der Darstellungsschicht über die Persistenzschicht eine entsprechende Prozedur auf.

Die Anwendung war somit direkt abhängig von der gewählten Persistenzlösung. Details aus der eigentlich untersten Schicht übertrugen sich bis fast hinauf in die oberste.

Zunächst stellte sich dieser Umstand nicht als Problem dar. Doch nach Jahren der Entwicklung änderten sich die Anforderungen an die Software. Die Anwendung sollte nun vom Datenbank-Server unabhängig sein. Bisher musste zu jeder Installation der Software auch der Datenbank-Server auf dem Rechner installiert werden.

Das führte dazu, dass die Rechner mit der entsprechenden Leistung – ausreichend für Datenbank und Anwendung – ausgestattet sein mussten. Günstige Laptops waren demnach keine Alternative. Zudem ging es nicht zuletzt darum Lizenzkosten für jede Installation einzusparen.

Durch die Vermischung von Anwendungslogik und Datenhaltung ließ sich die Persistenzschicht nicht ohne Weiteres austauschen. Zur Lösung des Problems wurde ein Service entwickelt, der die Interaktion mit der Datenbank übernahm.

Wäre die Anwendung ursprünglich nach dem „Ports and Adapters“-Muster entwickelt worden, hätte man nicht in eine komplett neue zusätzliche Anwendung investieren müssen. Ein einzelner neuer Adapter wäre ausreichend gewesen.

(ID:44687448)