© saicle/Shutterstock.com
Eventgetriebene Architektur

Bitte flach halten


Bestimmt haben Sie schon einmal von eventgetriebener Architektur gehört. Für das Buzzword-Bingo taugt dieser Begriff schon länger nicht mehr. In der Realität hat man allerdings tagtäglich mit dieser Architekturform zu tun. Gerade im Bereich der Web­entwicklung im Browser wird stark auf Events und deren Behandlung gesetzt. Jeder kennt es, und fast jeder macht es, und trotzdem stellt sich die Frage, in welchen Situationen spielt diese Form der Architektur eigentlich ihre Stärken aus, und wann sollten Sie besser auf einen eventgetriebenen Ansatz verzichten? Und worauf müssen Sie achten, wenn Sie sich schließlich für den Einsatz der eventgetriebenen Architektur entschieden haben? Antworten auf diese Fragen finden Sie in diesem Artikel.

Der Großteil dieses Artikels behandelt die eventgetriebene Architektur im Allgemeinen. Für die konkreten Beispiele kommt JavaScript zum Einsatz, da diese Sprache die eventgetriebene Architektur unterstützt und der Browser als Laufzeitumgebung selbst Elemente dieser Architektur beinhaltet.

Grundlagen der eventgetriebenen Architektur

Ein Event bezeichnet ein Ereignis innerhalb eines Systems beziehungsweise einer Software. Die Gründe, aus denen ein solches Ereignis ausgelöst wurde, können die verschiedensten sein. Ein Ereignis kann sowohl der Tastendruck eines Benutzers sein als auch der Eingang einer Anfrage an einen Webserver. In der eventgetriebenen Entwicklung ist ein Event mehr als nur der reine Hinweis „Hier ist irgend etwas passiert!“. Grundsätzlich ist ein Event nichts anderes als eine Nachricht von einer Komponente an eine andere. An ein Event werden ganz bestimmte Anforderungen gestellt. Das Event benötigt zunächst einen Namen. Außerdem werden neben dem Namen weitere Nutzdaten mit dem Event übermittelt. Ein klassisches Beispiel für ein Event ist ein Klick auf einen Button. Der Name des Events ist in diesem Fall „click“. Die Informationen, die mit diesem Event übermittelt werden, beinhalten unter anderem, auf welches Element geklickt wurde und wo genau dieser Klick erfolgte. Dieses Beispiel zeigt auch einen der häufigsten Anwendungsfälle für Events, nämlich grafische Oberflächen. Jede Interaktion des Nutzers auf einer grafischen Oberfläche löst ein Event aus. Das bedeutet: Jeder Klick mit der Maus beziehungsweise jede Berührung eines Touchscreens ist ein Event. Aber auch jeder Tastendruck löst ein Event aus und bei der Bewegung der Maus wird sogar eine ganze Kaskade von Events gefeuert. Entwickeln Sie eine Webapplikation, die im Browser ausgeführt wird, können Sie mit JavaScript auf jedes dieser Events reagieren.

Auf die Events, die ein System wie beispielsweise der Browser wirft, können Sie über eine Callback-Funktion reagieren. Die JavaScript-Bibliothek jQuery vereinfacht und vereinheitlicht die Bindung von Callback-Funktionen auf Events.

Vor- und Nachteile der eventgetriebenen Architektur

Die eventgetriebene Architektur ist keine Wunderwaffe gegen alle Probleme, sondern hat wie jede andere Architekturform ihre Vor- und Nachteile, die sie für bestimmte Aufgabenstellungen besser geeignet macht als für andere. Die eventgetriebene Architektur kommt sehr häufig im Bereich der Entwicklung grafischer Oberflächen zum Einsatz. Der Grund hierfür ist, dass die Interaktion der Benutzer schlecht in prozeduralem Code abzubilden ist. Der Eingriff des Benutzers ist für das System in den seltensten Fällen genau absehbar. Deswegen wartet das System auf die Eingabe und reagiert dann mit der Abarbeitung einer bestimmten Routine. Dieses Prinzip gilt sowohl für die Entwicklung von Desktopapplikationen wie auch für Webapplikationen. Der Vorteil einer solchen asynchronen Abarbeitung von Quellcode ist, dass die Applikationslogik ausgeführt wird, sobald sie gebraucht wird, nämlich genau im Falle des Auftretens des Events.

Das Argument, das in den meisten Fällen für eine eventgetriebene Entwicklung spricht, ist die lose Kopplung der Komponenten. Die Kopplung zwischen Komponenten gibt an, wie sehr sie voneinander abhängen. Bei einer engen Kopplung sind die Komponenten ineinander verzahnt und können nur mit größerem Aufwand ausgetauscht oder unabhängig voneinander betrieben werden. Die lose Kopplung in der eventgetriebenen Architektur wird erreicht, indem die Komponenten nur durch Nachrichten kommunizieren und so eine einheitliche Schnittstelle geschaffen wird. Neben den Events gibt es keine weitere Verbindung.

Ein weiterer Vorteil, der mit einer gewissen Beschränkung einhergeht, ist, dass der Informationsaustausch zwischen den Komponenten gewissen Konventionen unterworfen ist. Die Quelle der Events verfügt über ein begrenztes Repertoire an verschiedenen Events, die sie auslösen kann. Der Empfänger eines Events kennt entweder das gesamte Repertoire oder weiß, dass ein bestimmtes Event ausgelöst werden kann und welche Informationen mit diesem Event übermittelt werden. Diese Voraussetzung muss gegeben sein, damit Quelle und Empfänger die gleiche Sprache sprechen. Mit einer eventgetriebenen Architektur gewinnen Sie neben der Entkoppelung der einzelnen Systemkomponenten zusätzliche Flexibilität. Bei der prozeduralen Programmierung und auch in der normalen Objektorientierung platzieren Sie Funktionsaufrufe direkt im Programmfluss und zwar dort, wo Sie möchten, dass die jeweilige Routine ausgeführt wird. Bei einer eventgetriebenen Architektur haben Sie eine Referenz auf das Objekt, das ein bestimmtes Ereignis auslösen kann und registrieren dort die Routine, die ausgeführt werden soll. Bei einem Umbau oder einer Erweiterung der Software müssen Sie nicht den Quellcode anpassen, der für das Event verantwortlich ist, sondern können sich um die Behandlung des Events kümmern. Eine weitere Stärke ist, dass Sie beliebig viele so genannte Event Handler, also Routinen zur Behandlung eines Events, für ein Event registrieren können. Diese werden dann alle beim Eintreten des Events unabhängig voneinander ausgeführt.

Grundsätzlich gilt für die eventgetriebene Architektur, dass sie verhältnismäßig einfach zu schreiben ist. Im einfachsten Fall müssen Sie nur wissen, dass es ein bestimmtes Event gibt und können dann eine entsprechende Routine dafür registrieren. Werden mit einem Event weitere Daten übermittelt, müssen Sie natürlich auch noch wissen, wie diese Informationen strukturiert sind,...

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