Im zweiten Teil dieser Serie haben wir gesehen, welche Bausteine eine Event-getriebene Architektur ausmachen: Commands, Events, Projections und Event Streams. Dabei spielen Events eine zentrale Rolle – sie sind die Sprache, in der das System erzählt, was passiert ist.

Doch was genau ist ein Event eigentlich? Wie benennt man es? Und wie stellt man sicher, dass es fachlich sinnvoll, verständlich und nützlich ist?

Events sind fachliche Tatsachen

Ein Event beschreibt etwas, das in der Vergangenheit liegt und fachlich bedeutsam ist. Es geht nicht um technische Details („Request empfangen“ oder „Datenbankverbindung geöffnet“), sondern um Fakten, die für die Domäne relevant sind: „Buch wurde ausgeliehen“, „Mahngebühr wurde berechnet“ oder „Adresse wurde umgemeldet“.

Diese Ereignisse sind die kleinste gemeinsame Sprache zwischen Fachlichkeit und Technik. Sie dokumentieren Entscheidungen, Abläufe und Zustandsänderungen – nicht als Nachgedanke, sondern als primäres Modell.

Die Sprache der Fachlichkeit

Events sollten so formuliert sein, dass sie auch (beziehungsweise vor allem) von Fachleuten verstanden werden und – im Idealfall – wurden sie sogar gemeinsam mit ihnen entwickelt. Es geht darum, eine gemeinsame Sprache zu finden, die sowohl die Business-Perspektive als auch die technische Umsetzung trägt.

Ein gutes Event erfüllt folgende Kriterien:

• Es beschreibt eine Tatsache, keine Absicht, keinen Wunsch, keine Prognose.
• Es ist aus Sicht der Domäne verständlich und nachvollziehbar.
• Es benennt, was passiert ist, und nicht, wie es implementiert wurde.

Beispiel:

• Nicht „book created“, sondern „Buch wurde in den Bestand aufgenommen“.
• Nicht „book updated“, sondern „Buch wurde verliehen“.

Kein technisches Artefakt

Events sind keine Logzeilen, keine Debug-Ausgaben und keine reinen Transportformate. Sie bilden tatsächlich den fachlichen Kern dessen, was das System ausdrücken soll. Man kann sich ein Event daher wie einen Eintrag in einem Geschäftsbuch vorstellen – etwas, das dauerhaft dokumentiert, was geschehen ist, und auf dessen Basis Entscheidungen getroffen werden.

Wer Events als rein technische Hilfsmittel betrachtet, läuft Gefahr, ihre Bedeutung zu verwässern. Stattdessen sollten Events präzise benannt und stabil gehalten werden – denn sie bilden die langfristige Wahrheit des Systems.

Stabilität und Entwicklung

Events sind in der Regel unveränderlich. Sie werden erzeugt, gespeichert und danach nicht mehr verändert. Das bedeutet: Ein einmal veröffentlichtes Event ist Teil der Historie und muss als solches erhalten bleiben. Wenn sich Anforderungen ändern, sollte man nicht bereits vorhandene Events „anpassen“, sondern ergänzende Events einführen.

Diese Stabilität erlaubt es, Projections zu rekonstruieren, Prozesse zu debuggen und neue Anforderungen auf Basis der bestehenden Historie umzusetzen – zum Beispiel durch das Nachverarbeiten alter Events mit neuer Logik.

Veröffentlichung und Reaktion

Wenn ein Event entstanden ist, kann es nicht nur im eigenen System genutzt werden – sondern auch veröffentlicht werden. Oft geschieht das über eine Message Queue oder einen Event Bus. Dadurch können andere Teile des Systems (oder andere Systeme) darauf reagieren, ohne dass es eine direkte Kopplung gibt.

Das bedeutet: Events sind nicht nur Daten – sie sind ein Vertrag. Ein Versprechen, dass ein bestimmter Zustand eingetreten ist – und dass man sich darauf verlassen kann.

Was kommt als Nächstes?

Im nächsten Teil schauen wir uns an, was Event-getriebene Architektur wirklich bedeutet – und was häufig damit verwechselt wird. Denn nicht überall, wo Events draufstehen, ist auch Event-getriebene Architektur drin.

(mai)

Nicht nur Microsoft bietet GUI-Frameworks für .NET an. In den letzten beiden Teilen dieser Artikelserie soll es um die Vor- und Nachteile solcher Frameworks gehen. Dieser Beitrag stellt zunächst Wisej.NET vor, das Windows Forms sehr ähnlich ist, aber plattformneutral läuft. Der zweite plattformneutrale Kandidat, Avalonia, ist hingegen an Windows Presentation Foundation (WPF) angelehnt.

Wisej.NET

Wisej.NET – von 2016 bis 2022 in den Versionen 1.x und 2.x nur Wisej genannt – ist ein Rapid-Application-Development-Werkzeug für HTML-basierte Web- und Hybridanwendungen. Dahinter steht die 1998 gegründete US-amerikanische Firma Ice Tea Group LLC mit Sitz in Washington, D.C., die aus dem Umfeld von Gupta/Centura stammt, sich aber seit vielen Jahren auf dem .NET-Markt etabliert hat.

Wisej.NET verfolgt die gleiche Grundidee wie Blazor Server, das heißt, die Anwendung läuft auf dem Server, empfängt Benutzeraktionen und sendet Änderungen der HTML-Oberfläche über das Netzwerk zum Webbrowser. Der Chefentwickler von Wisej.NET, Gianluca Pivato, hält darauf sogar ein Patent unter dem Titel „Pixel perfect real-time web application framework„, bei dem man sich fragen kann, ob Blazor Server nicht dagegen verstößt.

Serverseitig lief Wisej.NET in den Versionen 1.0 und 2.0 nur auf dem klassischen .NET Framework auf Windows. Seit Version 3.0 ist auch das moderne .NET möglich, mit Windows oder Linux als Server. Der Serverprozess basiert dann auf ASP.NET Core. Als Programmiersprachen sind neben C# auch Visual Basic .NET und F# möglich. Auf der Clientseite setzt Wisej.NET auf das von der deutschen Firma 1&1 entwickelte JavaScript-basierte Webfrontend-Framework qooxdoo (gesprochen „kuckst du“).

Bei der Datenübertragung zwischen Server und Client ist neben WebSockets auch HTTP(S) möglich. Die Übertragung der DOM-Unterschiede vom Server zum Client ist effizienter als bei Blazor Server. Allerdings wird beim ersten Seitenaufruf mehr in den Browser geladen. Genau wie Blazor Server ist Wisej.NET nicht offlinefähig und alle Nutzer teilen sich die Serverressourcen. Wisej.NET kommt aber besser mit einem Reload im Browser zurecht als Blazor Server, da es den Anwendungszustand erhält. Bei Blazor Server geht der Anwendungszustand derzeit bei einem Reload immer verloren, wobei Microsoft für .NET 10.0 hier eine Verbesserung plant.

Wisej.NET ist Windows Forms sehr ähnlich. Es gibt sogar die Möglichkeit, bestehende Windows-Forms-Anwendungen nach Wisej.NET zu migrieren, also klassische Windows-Desktop-Anwendungen in den Browser und auf Mobilgeräte zu bringen. Im Wesentlichen muss man Assembly-Referenzen und Namensräume (aus dem Namensraum System.Windows.Forms wird Wisej.Web) ändern, was per Suchen und Ersetzen geht. Im Detail gibt es aber kleinere Unterschiede.

Abbildung 1 zeigt eine Windows-Forms-Anwendung und das nach Wisej.NET migrierte Pendant: Der modale Dialog graut das Hauptfenster aus, was bei Windows Forms nicht automatisch passiert. Die Steuerelemente sind bei Wisej.NET moderner und im Standard größer. Das Browserfenster in der Abbildung läuft dabei nur mit Zoomfaktor 80 Prozent.

Auch bei der API gibt es Unterschiede, die schon bei der kleinen Beispielanwendung in Abbildung 1 auffallen. Zum Beispiel setzt man in Wisej.NET die Hintergrundfarbe im GridView-Steuerelement mitthis.C_Tasks.BackColor = SystemColors.GradientInactiveCaption statt dem in Windows Forms verwendeten this.C_Tasks.BackgroundColor = SystemColors.GradientInactiveCaption. Wisej.NET ist hier einheitlicher, denn BackColor verwenden die meisten Steuerelemente in Windows Forms.

Bei den Steuerelementen ToolBar, StatusBar, ContextMenu, MainMenu und MenuBar ist Wisej.NET ebenfalls konsistenter, zum Beispiel wird aus

C_Status.AutoSize = true;

ein

C_Status.AutoSize = Wisej.Web.StatusBarPanelAutoSize.Spring;

In Windows Forms hat das Steuerelement StatusBarPanel die Eigenschaft StatusBarPanelAutoSize, dahingegen ToolStripStatusLabel nur ein AutoSize = true oder false.

Auch nach dem Setzen der Farbe für den GridView-Hintergrund und den zugehörigen Zellhintergrund auf hellblau erscheinen die Zeilen bei Wisej.NET immer noch in Weiß (siehe rechts in Abbildung 1). Um das zu lösen, muss man zusätzlich in das Theme in der Datei App.mixin.theme eingreifen:

{
 "colors": {
   "table-row-background": "#d7e4f2"
 }
}

Ein solches Theming gibt es in Windows Forms gar nicht, zumindest nicht ohne Drittanbieterbibliothek. Abbildung 2 zeigt im Hintergrund das GridView-Steuerelement mit einheitlicher Hintergrundfarbe, wie in der Windows-Forms-Anwendung links in Abbildung 1.

Für die Migration von Windows Forms zu Wisej.NET gibt es auch ein Werkzeug, das man allerdings nicht erwerben kann. Die Migration ist vielmehr eine angebotene Dienstleistung, an deren Ende der Auftraggeber eine lauffähige Wisej.NET-Anwendung inklusive Quellcode erhält. In unseren Gefilden macht diese Migration die Firma Fecher GmbH. Sie bietet die Migration nach Wisej.NET nicht nur von Windows Forms, sondern auch von WPF, Visual Basic 6, Microsoft Access und Gupta an. Projekte für die Migration von Windows-Lösungen bietet auch die Ice Tea Group direkt an.

Anders als Blazor Server hat Wisej.NET ein Session-Timeout nach 120 Sekunden Inaktivität und zeigt dann einen einminütigen Countdown zum Beenden der Anwendung (siehe Abbildung 2). Wenn der Benutzer oder die Benutzerin nicht reagiert, wird die Wisej.NET-Anwendung beendet und alle Ressourcen auf dem Webserver freigegeben. Entwicklerinnen und Entwickler können diese Zeit anpassen und wie bei Blazor Server auf unbegrenzt setzen, also solange der Browser lebt. Auch der Countdown lässt sich anpassen.

Anders als bei der aktuellen Blazor-Server-Version in .NET 9.0 können Entwicklerinnen und Entwickler in dem Wisej.NET-Serverprozess auch einstellen, dass Sitzungen nach Beenden des Browsers erhalten bleiben und auf Basis einer im Local Storage des Browsers abgelegten Session-ID später wieder aufgenommen werden können.

Wisej.NET bietet für die Entwicklung einen in Visual Studio integrierten WYSIWYG-Designer an, den man über die Visual Studio Extensions oder die Wisej-Website installieren kann und der dem Windows-Forms-Designer sehr ähnlich ist (siehe Abbildung 3). Genau wie bei Windows Forms generiert der Designer kein Markup, sondern Programmcode.

Wisej.NET liefert zahlreiche Steuerelemente im Grundpaket (.NET-Namensraum Wisej.Web) oder als Extension, auch höherwertige Steuerelemente wie ein editierbares Datagrid, verschiedene Diagrammtypen, einen Kalender, ein Ribbon, Anzeige von Microsoft-Office-Dokumenten sowie ein Theming (dafür gibt es einen eigenen Theme Builder als Windows-Anwendung). Die Steuerelemente kann man sich auf einer webbasierten Demonstrationsseite ansehen.

Entwicklerinnen und Entwickler müssen sich bei der Webentwicklung mit Wisej.NET nicht mit HTML, CSS und JavaScript auseinandersetzen, denn es ermöglicht eine komponentenbasierte Abstraktion von den Webtechniken, aus denen das Document Object Model generiert wird. Freilich kann man Inseln von HTML erschaffen; dafür gibt es Wisej.NET-Steuerelemente wie HtmlPanel und einen Extender für JavaScript und CSS. Entwicklerinnen und Entwickler können also wahlweise selbst JavaScript schreiben.

Es gibt zwar keine dedizierte Komponentenbibliothek eines Drittanbieters für Wisej.NET, aber das GUI-Framework kann beliebige Web-Komponentenbibliotheken nutzen, die auf HTML, CSS und JavaScript basieren (zum Beispiel jQuery, DevExpress DevExtreme, Syncfusion EJ1/EJ2, Telerik Kendo UI, Infragistics Ignite UI und TextControl). Premium Extensions vereinfachen deren Integration. Genau wie Microsoft mit seinen Smart Components arbeitet auch Wisej.NET an der KI-Integration in die Steuerelemente.

Neben dem Deployment auf einen Webserver kann Wisej.NET auch eine ausführbare Datei für das Self-Hosting erzeugen. AOT-Kompilierung ist bisher nicht möglich.

Genau wie Blazor lässt sich Wisej.NET in .NET-MAUI-Anwendungen einbetten und dann ohne Webbrowser direkt auf Windows, macOS, iOS und Android betreiben (siehe Wisej.NET Hybrid). Diese hybriden Wisej.NET-Anwendungen können auch offline ohne einen Webserver laufen.

Wisej.NET hat einige namhafte Kunden (siehe Case Studies auf der Wisej-Website und unter madewithwisej.com) und ist regelmäßig auf deutschen Entwicklerkonferenzen vertreten. Man braucht für jeden Entwickler und jede Entwicklerin eine Lizenz, die je nach Leistungsumfang zwischen 1190 und 1690 Dollar kostet, wobei es Mengenrabatte gibt. Für nicht-kommerzielle Zwecke ist eine kostenfreie Community-Lizenz verfügbar. Der Betrieb der Wisej.NET-Anwendung erfordert eine Serverlizenz. Dabei reicht das Spektrum von einer kostenfreien Lizenz für bis zu 100 Clients ohne Premium Extensions und ohne Support bis hin zu einer Lizenz für rund 29.000 Dollar für bis zu 10.000 Clients.

Microsoft verwendet in .NET 9.0 das neue Sprachfeature „Partielle Properties“ aus C# 13.0 und erlaubt im Source Generator für reguläre Ausdrücke, der vor zwei Jahren eingeführt wurde. Darüber habe ich in meiner Blogserie zu .NET 7.0 berichtet. Neu in .NET 9.0 ist, dass Entwicklerinnen und Entwickler die Annotation [GeneratedRegex] nun nicht mehr nur für Methoden, sondern auch Properties verwenden können.

Folgendes Codebeispiel zeigt das Vorgehen am Beispiel der E-Mail-Adressen-Validierung:

using System.Text.RegularExpressions;
 
namespace NET9_Console.FCL90;
 
public partial class Checker_Alt // Partielle Klasse
{
 [GeneratedRegex(@"\w+([-+.']\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*")] // ALT: Auf Methode
 // Partielle Methode, die dann von SG implementiert wird
 public partial Regex EMailRegEx();
}
 
public partial class Checker_Neu // Partielle Klasse
{
 [GeneratedRegex(@"\w+([-+.']\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*")] // NEU: Auf Property
 // Partielles Property mit Getter, der dann von SG implementiert wird
 public partial Regex EMailRegEx { get; } 
}
 
public class FCL9_RegExSourceGenerator
{
 public void Run()
 {
  CUI.Demo(nameof(FCL9_RegExSourceGenerator));
  // Aufruf der partiellen Methode
  Console.WriteLine(new Checker_Alt().EMailRegEx().IsMatch("max@mustermann.de"));
  // Aufruf des partiellen Properties
  Console.WriteLine(new Checker_Neu().EMailRegEx.IsMatch("max@mustermann.de"));
 }
}

Der Source Generator erzeugt beim Kompilieren zur Entwicklungszeit den Inhalt der Methode und den Getter des partiellen Properties. Den generierten Programmcode findet man in der Datei RegexGenerator.g.cs im Ordner C:\Users\Benutzername\AppData\Local\Temp\VSGeneratedDocuments\GUID.

(rme)