Follow my new blog

Donnerstag, 5. Juli 2012

Flow Runtime Meets Event-Based Components

Dass die Flow Runtime ein Ersatz für Event-Based Components sein soll, hat nicht jedem Freund des Flow-Design geschmeckt. Nicht alle sind deshalb mit fliegenden Fahnen zu NPantaRhei übergelaufen.
Ok, ok, kann ich verstehen. Aber jetzt ist Schluss :-) Jetzt gehen Event-Based Components (EBC) nämlich auch mit der Flow Runtime. EBC werden von der Runtime einfach in Operationen “übersetzt”. Und das geht so:

class Rechenwerk
{
    public void Teilen(Tuple<int,int> input)
    {
        if (input.Item2 == 0)
            DivisionDurchNull(input);
        else
            Resultat(input.Item1/input.Item2);
    }
 
    public event Action<int> Resultat;
    public event Action<Tuple<int,int>> DivisionDurchNull;
}

Eine Instanz EBC-Klasse wird dann einfach bei der Konfiguration reingereicht:
var config = new FlowRuntimeConfiguration()
        …
        .AddEventBasedComponent("rechenwerk", new Rechenwerk());

Die Runtime analysiert die Klasse und bietet dann alle Methoden mit der Signatur
  • Action
  • Action<T>
als Input-Port an. Der Methodenname ist der Portname. In diesem Fall wäre es nur Teilen.

Alle öffentlichen Events mit ebensolcher Signatur erkennt die Runtime als Output-Ports. Der Event-Name ist der Portname.

Im Flow müssen dann die Ports explizit angegeben werden.

var config = new FlowRuntimeConfiguration()
                .AddStreamsFrom(@"
                                 /
                                 .in, rechenwerk.teilen                                                rechenwerk.resultat, .result
                                 rechenwerk.divisionDurchNull, .error
                                 ")…

image

Bei Func/Action-Operationen gibt es keine Portnamen, weil sie durch den Verwendungsort der Operationen automatisch unterschieden werden kann zwischen Input und Output. EBC sind also ausführlicher. Aber das ist ja auch Sinn der Aktion. Auf EBC werden Sie zurückgreifen, wenn Ihre Operationen mehrere Input- und/oder Output-Ports haben.

Ich hoffe, damit ist es nun für alle attraktiv, sich mit der Flow Runtime zu beschäftigen. Selbst wer ganz auf EBC eingeschossen ist, kann jetzt davon profitieren, dass Flows für die Runtime mit einem Visualizer definiert und sogar aus Assemblies wieder ausgelesen werden können. Oder er kann ganz einfach die Verarbeitung in einer EBC-Instanz in den Hintergrund legen. Oder sie kann Exceptions in einer EBC-Instanz mit einer Causality abfangen – selbst wenn es auf einem Hintergrund-Thread gekracht hat.

Enjoy EBC at the next level!

Kommentare:

Michael Kreich hat gesagt…

Das freut mich sehr, ich spiele seit ein paar Wochen mit EBC rum und wollte gerade in die Flow Runtime einsteigen, habe aber mit Bedauern festgestellt, dass alle meine Klassen ein zweites nicht-EBC-Gesicht bräuchten. Hooorray :-)

Ralf Westphal - One Man Think Tank hat gesagt…

@Michael: Freut mich, dass es dir nun leichter fällt, auf die Runtime umzusteigen.

Aber bedenke: Wenn du weiterhin "in EBC denkst" und nur deren Platinen durch Flows ersetzt, verschenkst du Potenzial.

Der Charme der Runtime ist, dass du Operationen als Funktionen oder Prozeduren implementieren kannst. EBC sind unhandlich grobgranular im Vergleich mit ihrem Zwang zu "1 Klasse pro Operation".

Deshalb kommen Sie auch jetzt erst in das Flow Runtime Bild. Sie sind nützlich hier und da, wenn Operationen wirklich mal mehrere Inputs brauchen. Oder mehr als 2 Outputs. Das sollte jedoch für die Lesbarkeit von Flows nur selten der Fall sein!.

Also: Versuche dich trotz dieses Features von EBC zu verabschieden.