Ereignisse verteilt einsetzen

Ereignisse einsetzen

Ereignisse sind tägliches Brot jedes C# Entwicklers. Vor allem bei der Entwicklung von Benutzeroberflächen, wird hauptsächlich mit Ereignissen gearbeitet. Möchte man z.B. bestimmten Code ausführen, wenn auf einem Windows-Fenster eine Schaltfläche angelickt wird, muss man dafür das Click-Ereignis der Schaltfläche abonnieren. Das hat jeder schon mal gemacht.

{code:c#} button1.Click += new EventHandler(button1_Click);

...

private void button1_Click(object sender, EventArgs e) { MessageBox.Show("Schaltfläche angeklickt."); } {code:c#}

Das ist nichts Neues. Aber wie funktioniert die Ereignisbehandlung, wenn die Komponente, welche das Ereignis anbietet, auf einem anderen Computer läuft? Mit den .NET Bordmitteln für verteilte Anwendungen WCF und .NET Remoting geht das nicht ohne Weiteres. Richtige Ereignisse, wie oben beschrieben, lassen sich mit WCF z.B. standardmäßig gar nicht abbilden. Um eine vergleichbare Funktionalität zu bekommen, müsste man da einen sog. Duplex Contract implementieren. Verglichen mit button1_Click ist das aber eine Menge Handarbeit.

Zyan dagegen macht Ereignisbehandlung im button1_Click-Stil ohne weiteres Zutun auch in verteilten Anwendungen möglich. Folgender Code läuft mit Zyan also ohne Probleme:

{code:c#} chatProxy = _connection.CreateProxy(); chatProxy.MessageReceived += new Action<string, string>(chatProxy_MessageReceived);

...

private void chatProxy_MessageReceived(string arg1, string arg2) { MessageBox.Show(string.Format("{0} sagt: {1}", arg1, arg2)); } {code:c#}

Damit das Ereignisfeuerwerk übers Netzwerk eine gelungene Komposition wird, ist allerdings folgendes zu beachten:

• Die Typen der Ereignisparameter müssen serialisierbar sein, damit die Übertragung übers Netzwerk funktionieren kann.
• Ereignisse, die eine Serverkomponente anbietet, müssen auch in deren Schnittstelle definiert werden, da die Clients nur die Schnittstelle kennen.
• Immer im Hinterkopf haben, dass Netzwerkzugriff wesentlich langsamer ist als direkter Zugriff auf den Arbeitsspeicher.
• Kann der Server beim Versuch eine Ereignisprozedur auf einem Client aufzurufen, den Client nicht erreichen, so wird dessen Ereignis-Abo entfernt und der Client wird nicht weiter benachrichtigt.
• Haben viele Clients ein Ereignis einer Server-Komponente abonniert, kann sich die Benachrichtigung verzögern, da die Aufrufliste des Ereignisses - wie bei lokalen Ereignissen auch - sequenziell abgearbeitet wird.
• Ereignisse funktionieren nicht in einer Cluster-Umgebung. Ein Client kann also nicht ein Ereignis von Komponente A auf Server X abonnieren und erwarten, dass Server Y dann benachrichtigt, wenn Server X nicht mehr online ist.

Ereignisse funktionieren mit jedem ProtocolSetup.

Hier finden Sie eine kleine Beispielanwendung, die einen Chat mit Events implementiert: Chat-Beispielprojekt