HowToCode: Wie bildet man einen Workflow im Code am besten ab?
Jede Anwendung basiert auf ein oder mehrere Aktionen, welche zum Teil von verschiedensten Dingen abhängen: Dem User, anderen Systemen, eingegebene Werte etc.
Meist spricht man von einem "Workflow", der in Software umgesetzt werden muss, doch wie bildet man diesen am "effektivsten" ab? If-Else Konstrukte oder "Workflow Engines" wie die Windows Workflow Foundation? Wie steht es mit der Testbarkeit? In diesem Post will ich ein paar Varianten vorstellen, bitte aber wieder ausdrücklich um Feedback, wie ihr dies handhabt.
Was ist bei "mir" alles ein Workflow?
Ohne jetzt auf wissenschaftliche Erklärungen einzugehen, möchte ich meine "Definition" von Workflow niederschreiben: Für mich ist so ziemlich alles ein Workflow. Jeder Login und Registrier-Prozess ist ein Workflow, der mehr oder weniger kompliziert ausfallen kann.
Einen User editieren oder löschen ist auch ein Workflow, da bestimmte Schritte im Code abgegangen werden müssen: Sind die Daten valide, gibt es den User überhaupt, darf der aktuell angemeldet User die Aktion ausführen und und und.
Szenario:
Unser Szenario ist wie beim letzten Mal eine Webanwendung, welche eine 3-Schichten Architektur implementiert. Ein User soll sich anmelden können, dabei wird geprüft, ob er bereits vorher einen Newsletter aboniert hat oder nicht und ob es sich um eine Privatperson handelt oder ein Unternehmen.
Vorher findet natürlich eine Validierung der Daten statt.
Die Logik möchte ich im "Service" halten. Wenn man dies kurz skizziert kommt man auf ein solches Bild – die Abfrage nach Privatperson oder Unternehmen hab ich aus Platzgründen weggelassen – man kann sich hier aber noch beliebig viele andere Bedingungen hinzufügen wenn man das möchte.
Wichtig: Saubere Architektur beibehalten & Testbar bleiben
Das Szenario ist für den Post auch etwas simpler gewählt, allerdings habe ich (wie bereits oben erwähnt) eine solche Struktur und möchte auch nur in den Services im Hintergrund Workflows einsetzen – weder das Repository noch das Front-End muss wissen, wie die Buisnesslogik etwas macht.
Variante A: Per Hand im Code
Ich schreib bei dieser Variante nur "Pseudocode":
public GenericResponse<User> Register(GenericRequest<User> registerRequest)
{
if(userRequest.Value == null)
{
throw new Exception();
}
if(!IValidationService.ValidateRequest(userRequest.Value))
{
throw new Exception();
}
bool hasNewsletter = false;
if(INewsletterService.GetUser(userRequest.Value.Id)) != null)
{
hasNewsletter = true;
}
...
}
Das war noch nicht der ganze Workflow (und in der Realität ist der Workflow noch etwas komplexer 
), allerdings (auch wenn er hier noch IMHO schön aussieht) immer größer, weil immer mehr if… Sachen hinzukommen.
Vorteil:
- Man braucht nichts neues lernen
_ Volle Kontrolle
- Durch die volle Kontrolle hat man keine Seiteneffekte, dass plötzlich der Service wild auf irgendwelche Datenbanken schreibt
- Testbar (je nach Code )
Nachteil:
- Es kann recht schnell Umfangreich werden
- Es wird mit der Zeit unübersichtlich
Variante B: Man nehme ein Workflow-Engine
Die zweite Variante wäre der Einsatz einer Workflow-Engine, z.B. die Windows Workflow Foundation. Ich möchte jetzt keine Einführung machen, weil ich selber dazu zu wenig weiß.
Es gibt jedoch auf den ersten Blick Designerunterstützung die ganz praktisch ist:
Allerdings scheiden sich die Geister ob sich der Einsatz lohnt oder nicht. Herr Schwichtenberg hat vor langer Zeit mal ein Blogpost über die Guten und weniger guten Dinge der WF geschrieben. Auch auf Stackoverflow ist man sich da nicht so einig ob es nun toll ist oder man lieber auf Version 2 warten sollte.
Zumal die Workflow Foundation die mit .NET 3.0 eingeführt wird mit .NET 4.0 nochmal komplett neugeschrieben wird. Auf den ersten Blick macht die Workflow-Foundation erst mal mehr Arbeit, auch in Rob Conerys MVC Storefront sah ich jetzt nicht unbedingt den Vorteil
Lohnt es sich trotzdem? Ist der Einarbeitungsaufwand hoch? Kann man es gut testen?
Variante C: ?
Weder mit Variante A noch Variante B scheinen mich komplett zu überzeugen. Wobei Variante B voller Tücken, Lernaufwand (+ Migration auf .NET 4.0) und Voodoo ist.
Aber vielleicht hab ich eine geniale Sache vergessen oder die WF ist besser als ich denke – daher bitte ich wieder um euer Feedback 
Wie würdet Ihr das obere Szenario abbilden?
About the author
Written by Robert Mühsig
Robert Mühsig (@robert0muehsig) ist Webentwickler und beschäftigt sich mit Web-Frameworks (vor allem dem ASP.NET MVC Framework) und scheut sich auch nicht vor Javascript. Ansonsten bloggt er über all jene Probleme, die ihm über den Weg laufen. Seit 2008 ist er Microsoft MVP für ASP.NET und er arbeitet bei der T-Systems Multimedia Solutions GmbH in Dresden. Treffen kann man ihn online via Twitter (@robert0muehsig) oder dieser Seite oder bei der .NET User Group Dresden.
Oliver Guhr
12. February 2009
In deinem Fall würde ich dir zur WF raten. Dein Workflow ist zu komplex(ich kenn ja den rest) um ihn schön mit if’s und else’s zu bauen und einfach genug um ihn mit standard Elementen der WF umzusetzen. Ich denke du kannst deinen Workflow ohne großen Zauber relativ schnell mit der WF umsetzen.
Der Softwareentwickler Blog
12. February 2009
Wenn ich entwickel, dann plane ich meinen Programmablauf (also den Workflow) und erstelle erstmal ein Struktogramm auf Papier.
Dies übertrage ich dann als Text in Kommentarform, ähnlich wie Du mit Deinem Pseudocode, erstmal in meine zukünftige Methode.
Und beginne ich zu programmieren und orientiere mich dabei an den Texten und nutze diese gleichzeitig als Kommentare für meinen Code.
Da ich komplexere Operationen meistens ausgliedere entsteht hierbei normalerweise auch nicht das Problem der Unübersichtlichkeit.
Ich hoffe, dass ich mich verständlich ausgedrückt hab.
Aber kannst Du mir mal sagen, was WF tatsächlich macht (also außer bunte Bildchen malen)? Wird anhand der Grafik Code im Hintergrund erzeugt oder wie soll WF mir das Arbeiten erleichtern? Alles was ich bisher gelesen hab hat mich nicht wirklich dazu gebracht mich damit weiter zu beschäftigen, andere Neuerungen waren da interessanter…
Christian Anderegg
15. April 2009
Die bunten Bildchen sind im Grunde nichts anderes als dein Struktogramm. Somit hättest du schon mal einen Arbeitsschritt gespart. (kein Umwandeln in Pseudocode)
Der Vorteil von WF besteht darin, dass man sich komplet auf die Logik des Programms konzentrieren kann. Das heisst, man erstellt zuerst das Struktogramm (gibt verschieden komplexe Varianten) und danach werden die einzelnen Activities programmiert. (wenn du das einmal verstanden hast, kanst du am Besten beim Erstellen des "Knotenpunkts" bereits die Activity programmieren.)
Dies ist aber nicht der einzige Vorteil. Die von dir erstellten Activities kann man für jedes beliebige Projekt (natürlich in WF) verwenden. Das heisst, wenn du einmal die Activity "verbinde mit Server" erstellt hast, kannst du dieses immer wieder verwenden. (wahrscheinlich musst du dann noch den ConnectionString ändern aber dies wird mit den Properties gemacht, siehe Variablen und Argumente in WF 4.0)
Falls ich ein bisschen unverständlich geschrieben habe, möchte ich mich dafür entschuldigen. Falls du noch weitere Fragen hast, kann ich dir die Videos von der PDC2008 empfehlen (A first look into WF 4.0 und Extending with Custom Activities)
Viel Spass