Wann wird Windows Workflow Foundation verwendet? [geschlossen]

Einige Dinge sind einfacher von Hand (Code) zu implementieren, andere sind einfacher durch WF. Es sieht so aus, als ob WF verwendet werden kann, um (fast) jede Art von Algorithmus zu erstellen. Also (theoretisch) kann ich meine gesamte Logik in WF ausführen, aber es ist wahrscheinlich eine schlechte Idee, dies für alle Projekte zu tun.

In welchen Situationen ist es eine gute Idee, WF zu verwenden, und wann wird es die Dinge schwieriger machen, als sie sein müssen? Was sind Vor- und Nachteile / Kosten von WF im Vergleich zur manuellen Codierung?

Möglicherweise benötigen Sie WF nur, wenn eine der folgenden Bedingungen erfüllt ist:

1. Sie haben einen langjährigen Prozess.
2. Sie haben einen Prozess, der sich häufig ändert.
3. Sie möchten ein visuelles Modell des Prozesses.

Weitere Informationen finden Sie in Paul Andrews Beitrag: Wofür soll Windows Workflow Foundation verwendet werden?

Bitte verwechseln oder verknüpfen Sie WF nicht mit visueller Programmierung jeglicher Art. Es ist falsch und kann zu sehr schlechten Architektur- / Designentscheidungen führen.

Noch nie. Sie werden es wahrscheinlich bereuen:

• Steile Lernkurve
• Schwer zu debuggen
• Schwer zu pflegen
• Bietet nicht genügend Leistung, Flexibilität oder Produktivitätsgewinn, um seine Verwendung zu rechtfertigen
• Kann und wird den Anwendungsstatus beschädigen, der nicht wiederhergestellt werden kann

Das einzige Mal, dass ich mir vorstellen könnte, WF zu verwenden, wäre, wenn ich den Designer für einen Endbenutzer hosten wollte und wahrscheinlich auch dann nicht.

Vertrauen Sie mir, nichts wird jemals so einfach, leistungsfähig oder flexibel sein wie der Code, den Sie schreiben, um genau das zu tun, was Sie brauchen. Bleib weg von WF.

Natürlich ist dies nur meine Meinung, aber ich denke, es ist eine verdammt gute. :) :)

Der von WF generierte Code ist böse. Der Wert, den WF bringt, liegt in der visuellen Darstellung des Systems, obwohl ich noch nichts gesehen habe (6-7 Projekte bei der Arbeit mit WF, an denen ich beteiligt war), bei denen ich ein einfacheres handcodiertes Projekt nicht bevorzugt hätte .

Wenn Sie die Persistenz- und Nachverfolgungsfunktionen (die meiner Meinung nach die Hauptfunktionen sind) nicht benötigen, sollten Sie Workflow Foundation im Allgemeinen nicht verwenden.

Hier sind die Vor- und Nachteile von Workflow Foundation, die ich aus meiner Erfahrung gesammelt habe:

Vorteile

• Persistenz: Wenn Sie viele lange laufende Prozesse haben (denken Sie an Tage, Wochen, Monate), sind Workflows dafür großartig. Inaktive Workflow-Instanzen bleiben in der Datenbank erhalten, sodass kein Speicher belegt wird.
• Nachverfolgung: WF bietet den Mechanismus zum Nachverfolgen jeder in einem Workflow ausgeführten Aktivität
• * Visual Designer: Ich habe dies als * angegeben, da ich denke, dass dies wirklich nur für Marketingzwecke nützlich ist. Als Entwickler schreibe ich lieber Code, als Dinge visuell zusammenzufügen. Und wenn ein Nicht-Entwickler Workflows erstellt, kommt es häufig zu einem großen Durcheinander.

Nachteile

• Programmiermodell: Ihre Programmierfunktionen sind wirklich eingeschränkt. Denken Sie an all die großartigen Funktionen, die Sie in C # haben, und vergessen Sie sie dann. Einfache ein- oder zweizeilige Anweisungen in C # werden zu ziemlich großen Blockaktivitäten. Dies ist besonders ein Problem für die Eingabevalidierung. Wenn Sie jedoch wirklich darauf achten, nur die Logik auf hoher Ebene in den Workflows und alles andere in C # beizubehalten, ist dies möglicherweise kein Problem.
• Leistung: Workflows belegen viel Speicher. Wenn Sie viele Workflows auf einem Server bereitstellen, stellen Sie sicher, dass Sie über jede Menge Speicher verfügen. Beachten Sie auch, dass Workflows viel langsamer sind als normaler C # -Code.
• Steile Lernkurve, schwer zu debuggen: Wie oben erwähnt. Sie werden viel Zeit damit verbringen, herauszufinden, wie Sie Dinge zum Laufen bringen und wie Sie am besten etwas tun können.
• Inkompatibilität der Workflow-Version: Wenn Sie einen Workflow dauerhaft bereitstellen und Aktualisierungen am Workflow vornehmen müssen, sind die alten Workflow-Instanzen nicht mehr kompatibel. Angeblich ist dies in .NET 4.5 behoben.
• Sie müssen VB-Ausdrücke verwenden (.NET 4.5 ermöglicht C # -Ausdrücke).
• Nicht flexibel: Wenn Sie spezielle oder spezifische Funktionen benötigen, die nicht von Workflow Foundation bereitgestellt werden, bereiten Sie sich auf große Schmerzen vor. In einigen Fällen ist dies möglicherweise nicht möglich. Wer weiß, bis Sie es versuchen? Hier besteht ein großes Risiko.
• WCF-XAML-Dienste ohne Schnittstellen: Normalerweise entwickeln Sie mit WCF-Diensten gegen eine Schnittstelle. Mit WCF XAML-Diensten können Sie nicht sicherstellen, dass ein WCF XAML-Dienst alles in einer Schnittstelle implementiert hat. Sie müssen nicht einmal eine Schnittstelle definieren. (Soweit ich weiss...)

Der Hauptgrund, warum ich Workflow Foundation verwendet habe, ist, wie viel Sie in Bezug auf Nachverfolgung und Persistenz sofort einsatzbereit sind. Es ist sehr einfach, den Persistenzdienst zum Laufen zu bringen, was Zuverlässigkeit und Lastverteilung zwischen mehreren Instanzen und Hosts ermöglicht.

Andererseits sind genau wie bei Formular-Apps die Codemuster, zu denen der Workflow-Designer Sie drängt, schlecht. Sie können jedoch Probleme vermeiden, indem Sie keinen Code in den Workflow schreiben und alle Arbeiten an andere Klassen delegieren, die besser organisiert und einheitlich getestet werden können als der Workflow. Dann erhalten Sie den coolen visuellen Aspekt des Designers ohne die Menge Spaghetti-Code dahinter.

Persönlich bin ich nicht auf WF verkauft. Die Nützlichkeit war für mich nicht so offensichtlich wie für andere neue MS-Technologien wie WPF oder WCF.

Ich denke, WF wird in Zukunft stark in Geschäftsanwendungen eingesetzt, aber ich habe nicht vor, es zu verwenden, da es nicht das richtige Werkzeug für den Job für meine Projekte zu sein scheint.

Das Unternehmen, für das ich derzeit arbeite, richtet eine Windows Workflow Foundation (WF) ein. Die Gründe für die Verwendung waren, dass sich die Regeln häufig ändern und sie gezwungen sind, die verschiedenen DLLs usw. und damit ihre Lösung neu zu kompilieren war, die Regeln in die DB zu stellen und von dort aus aufzurufen. Auf diese Weise könnten sie die Regeln ändern und müssen die DLLs usw. nicht neu kompilieren und verteilen.

Windows Workflows verführen nicht-codierende IT-Manager, BAs und dergleichen wie sein Cousin BizTalk, aber in der Praxis sind Unit-Tests, Debugging und Codeabdeckung nur drei der vielen Fallstricke. Sie können einige davon überwinden, aber Sie müssen viel in das Erreichen dieses Ziels investieren, während Sie mit einfachem Code nur das bekommen. Wenn Sie wirklich eine langfristige Anforderung haben, brauchen Sie wahrscheinlich etwas Anspruchsvolleres. Ich habe das Argument gehört, dass neue xaml-Dateien ohne erneutes Kompilieren von DLLs in die Produktion gebracht werden können, aber ehrlich gesagt könnte die Zeit, die Workflows benötigen, besser genutzt werden, um Ihre kontinuierliche Integration so weit zu verbessern, dass kompilierte Bereitstellungen kein Problem mehr darstellen.

Ich würde es in jeder Umgebung verwenden, in der ich mit Workflows arbeiten muss. Wenn ich es jedoch in Verbindung mit K2 oder sogar SharePoint 2007 verwende, ist die Leistung der Plattform wirklich nützlich. Bei der Entwicklung von Geschäftsanwendungen mit einem BI-Spezialisten wird die Verwendung der Plattform empfohlen. Dies ist normalerweise nur für die Rationalisierung und Verbesserung von Geschäftsprozessen relevant.

Für den Rekord wurde WF in Zusammenarbeit mit dem Entwicklungsteam von K2 entwickelt und der neue K2 Blackpearl basiert auf WF, ebenso wie die Workflow-Engines von MOSS 2007 und WSS 3.0.

Wenn Sie nicht alle diese Codes manuell schreiben möchten, um die visuelle Oberfläche, das Tracking und die Persistenz beizubehalten, ist es eine gute Wahl, für WF zu stimmen.

Ich verwende den Windows-Workflow seit Monaten, um benutzerdefinierte Aktivitäten und einen neu gehosteten Designer zu entwickeln, mit dem Nicht-Entwickler Workflows erstellen können. WF ist sehr leistungsfähig, aber es ist nur so gut wie die benutzerdefinierten Aktivitäten, die von Entwicklern erstellt werden. Wenn es darauf ankommt, müsste ein Entwickler Workflows überprüfen, die von Nicht-Entwicklern erstellt wurden, um sie zu testen und zu debuggen, aber von dem Punkt an, an dem sie Entwürfe für Workflows erstellen können - das ist fantastisch.

In Fällen mit lang laufenden Prozessen ist WF ein guter Tech-Stack, wenn Sie Prozesse dynamisch aktualisieren müssen - ohne neu installieren / herunterladen oder irgendetwas tun zu müssen. Fügen Sie einfach die neuen XAML-Dateien zu einem Verzeichnis hinzu, und Ihre Architektur sollte es sein Richten Sie die Versionierung ein, um die alte zu verschrotten und die neue zu verwenden.