Workflow?

[implementation]

Ich stoße immer wieder über den Begriff Workflow, verstehe aber nicht ganz, was das ist.
Gerade in .Net taucht er ja immer wieder auf.

Die Wikipedia-Seite hilft mir nicht allzu sehr weiter.

Wäre jemand so nett mir zu erklären:

1. Was sind Workflows?
2. Wie nutzt man Workflows?
3. Wann sind Workflows nützlich?

[BUG]

Achtung:
Zusammengereimtes folgt, Fehler dringend ankreiden :mrgreen:


Soweit es mir begegnet ist, ist ein Workflow der Ablauf, um eine bestimmte Aufgabe zu erledigen.
Dabei ist nicht nur interessant, was gemacht wird, sondern auch wie.

Eine Verbessung des Workflows zum Schreiben eines C#-Programmes könnte zB. sein, das du die GUI nicht selbst in C# coden musst, sondern sie in XAML mit entsprechenden Programmen designen (lassen) kannst.

[Medium]

Einfach mal übersetzen: Arbeitsfluss - Das trifft die sache schon recht prima.

[Assarbad]

Zitat:

Zitat von Medium (Beitrag 1085259)

Einfach mal übersetzen: Arbeitsfluss

But what about ze buzzwords zen? ... zey need to be Engrish!!!! :stupid:

[Luckie]

Mal ein Beispiel. Stell du vor du hast eine Anwendung, bei der ständig irgendwelche Dialoge aufpopen, mit eigentlich unwichtigen Meldung. Du kannst dir vorstellen, dass der Workflow für den Benutzer nicht sehr angenehm ist. Oder wenn man unnötige Klicks benötigt, um etwas zu erreichen. Das wäre auch kein sehr angenehmer Workflow.

Kleiner Tipp: Solche Buzzword, wie Oliver schon gesagt hat, einfach übersetzen und nicht zu viel hinein interpretieren.

[Phoenix]

Etwas abstrakt: In einem Workfluss definierst Du Zustände der Arbeit, und Übergänge zwischen diesen Zuständen. Dazu dann noch Regeln, unter welchen Umständen einer dieser Zustandsübergänge überhaupt möglich ist. Klassiker Bugtracker: Ticket neu. Übergänge zu Abgelehnt und Zugewiesen. Beide Übergänge dürfen nur von einem Teamleiter ausgelöst werden, bei zugewiesen muss ein Entwickler ausgewählt werden, bei Abgelehnt eine Begründung eingegeben.

Eine ordentliche Workflow-Engine (z.B. die aus .NET 4.0, NICHT die aus den früheren Versionen) erlaubt es Dir, diese Zustände und Übergänge leicht zu definieren und die Ausführung zu überwachen. Die Workflow foundation in .NET bietet Dir darüber hinaus auch die Speicherung der Workflow-Zustände in einer Art die es erlaubt, verteilte Workflows zu modellieren (d.h. der Statusübergang kann in einer anderen Software auf einem anderen System passieren, was z.B. bei Bestellsystemen der Fall sein kann). Ausserdem laufen dort die Statusübergänge meist transaktionell durch. Und genau an der Stelle fangen die Systeme dann auch an, Dir als Entwickler die Arbeit abzunehmen. Einen Workflow mit ein paar Enums bekommt man relativ easy hin, aber wenn es dann um die konsequente Überwachung, Zusicherung der Zustände und die Persistenz geht fängt es an, viel Code zu werden. Und diesen Code nehmen einem die Systeme dann irgendwann ab.

[Luckie]

Mist, jetzt hat es doch noch jemand geschafft die Blase mit Substanz zu füllen. ;)

[implementation]

Zitat:

Zitat von Phoenix (Beitrag 1085282)

Etwas abstrakt: In einem Workfluss definierst Du Zustände der Arbeit, und Übergänge zwischen diesen Zuständen. Dazu dann noch Regeln, unter welchen Umständen einer dieser Zustandsübergänge überhaupt möglich ist. Klassiker Bugtracker: Ticket neu. Übergänge zu Abgelehnt und Zugewiesen. Beide Übergänge dürfen nur von einem Teamleiter ausgelöst werden, bei zugewiesen muss ein Entwickler ausgewählt werden, bei Abgelehnt eine Begründung eingegeben.

Eine ordentliche Workflow-Engine (z.B. die aus .NET 4.0, NICHT die aus den früheren Versionen) erlaubt es Dir, diese Zustände und Übergänge leicht zu definieren und die Ausführung zu überwachen. Die Workflow foundation in .NET bietet Dir darüber hinaus auch die Speicherung der Workflow-Zustände in einer Art die es erlaubt, verteilte Workflows zu modellieren (d.h. der Statusübergang kann in einer anderen Software auf einem anderen System passieren, was z.B. bei Bestellsystemen der Fall sein kann). Ausserdem laufen dort die Statusübergänge meist transaktionell durch. Und genau an der Stelle fangen die Systeme dann auch an, Dir als Entwickler die Arbeit abzunehmen. Einen Workflow mit ein paar Enums bekommt man relativ easy hin, aber wenn es dann um die konsequente Überwachung, Zusicherung der Zustände und die Persistenz geht fängt es an, viel Code zu werden. Und diesen Code nehmen einem die Systeme dann irgendwann ab.

Danke, jetzt habe ich's verstanden! :thumb: