Kontrollflussarchitektur bei Ereignissen: Geschmackssache?!?

[stahli]

Ich verstehe Dein Anliegen nicht so richtig.

Im Regelfall sollte ein Ereignis m.E. unmittelbar behandelt werden.
Die Reihenfolge und Anzahl resultierender Behandlungen kann ggf. variieren und sollte i.d.R. keine schädlichen Auswirkungen haben.

Wenn es doch mal zu irgendwelchen Seiteneffekten kommt muss man diese entsprechend explizit berücksichtigen (durch Einsatz von Flags o.ä.).

Sofern man die Geschäftslogik und die GUI ordentlich voneinander trennt, hat man solche Probleme womöglich gar nicht. Bei der Delphi-Architektur verlangt das natürlich schon eine gewisse Selbstdisziplin.


Vielleicht bin ich aber auch auf dem völlig falschen Gleis und habe die Fragestellung überhaupt nicht verstanden...

[BrightAngel]

Zitat von stahli:

Im Regelfall sollte ein Ereignis m.E. unmittelbar behandelt werden.

Genau um dieses "unmittelbar" geht es: Dadurch, dass mehrere Listener informiert werden entsteht das Problem, dass das nicht "zeitgleich" passieren kann.

Zitat von stahli:

Die Reihenfolge und Anzahl resultierender Behandlungen kann ggf. variieren und sollte i.d.R. keine schädlichen Auswirkungen haben.

Genau. Das ist quasi das Ziel. Das stimmt halt nur, wenn zwischen den Ereignissen keine Abhängigkeit besteht. Teilweise gibt es die aber schon; bzw sind.

Zitat von stahli:

Sofern man die Geschäftslogik und die GUI ordentlich voneinander trennt, hat man solche Probleme womöglich gar nicht. Bei der Delphi-Architektur verlangt das natürlich schon eine gewisse Selbstdisziplin.

Klar, man plant da definitiv vorher. Dafür Entwirft man ja seine Software vorher Trotzdem geht das nicht immer perfekt und/oder mancherorts nur künstlich zum Beispiel durch das Einführen zusätzlicher Indirektion. Das kann auch nur in der GUI passieren, wenn mehrere Stellen der UI korrelieren und bei Änderungen miteinander reagieren.

Ich gebe zu, dass das alles ein wenig künstlich wirkt, aber ich bin auf der Suche nach einem möglichst schönen Paradigma was Ereignisse angehen.

Brighty

[ConnorMcLeod]

Das erinnert mich an SendMessage und PostMessage. Was wäre bei diesen die bessere Variante. Antwort: je nach Anwendungsfall

[stahli]

Zu dem Schluss komme ich auch.

Als Paradigma würde ich vielleicht formulieren: Abhängigkeiten zwischen Modulen und Ereignissen nach Möglichkeit vermeiden. Wo das nicht möglich ist, Einzelfall-Lösungen finden, die mit den Abhängigkeiten umgehen können (und die können ganz unterschiedlich ausfallen).

[Stevie]

Das Hauptproblem, was ich mit der unmittelbaren Verarbeitung eines Eventhandlers sehe, ist, dass möglicherweise die UI "einfriert", sollte das Event abarbeiten etwas länger dauern.
In solchen Fällen würde ich die Abarbeitung aber lieber asynchron durchführen (thread), um möglichst schnell wieder aus dem Event Trigger zurückzukehren.

Somit kannst du beide Fälle mit einem Modell abarbeiten ohne dir explizit irgendwelche States zu merken oder das ganze Eventsystem aufzublasen.

Alternativ schraubst du in deine Listener nen event/message bus und lässt den die Arbeit asynchron/verzögert erledigen.
Dort können dann auch doppelte Events ausgefiltert werden im Sinne von, ich muss nich erst das Event von "hat sich auf 3x9 geändert" feuern, wenn danach noch eins für "hat sich auf 2x9 geändert" in der Queue liegt.

In Frameworks with ReactiveX (leider gibts da *noch* keine Implementierung für Delphi) gibts da z.B. verschiedene Möglichkeiten für.