Wann verwenden Sie Windows Workflow Foundation?

Noch nie. Sie werden es wahrscheinlich bereuen:

• Steile Lernkurve
• Schwer zu debuggen
• Schwierig zu warten
• 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, an das ich mir die Verwendung von WF vorstellen konnte, ist, wenn ich den Designer für einen Endbenutzer hosten wollte und wahrscheinlich auch nicht.

Vertrauen Sie mir, nichts wird so einfach, kraftvoll oder flexibel sein wie der Code, den Sie schreiben, um genau das zu tun, was Sie benötigen. Bleiben Sie weg von WF.

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

Der von WF generierte Code ist unangenehm. Der Wert, den WF bringt, liegt in der visuellen Darstellung des Systems, obwohl ich bisher noch nichts gesehen habe (6-7 Projekte bei der Arbeit mit WF, an denen ich beteiligt war) Ich habe kein einfacheres handcodiertes Projekt vorgezogen.

Wenn Sie die Persistenz- und Nachverfolgungsfunktionen (die meiner Meinung nach die Hauptmerkmale sind) nicht benötigen, sollten Sie im Allgemeinen keine Workflow Foundation 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 (Denktage, Wochen, Monate), dann sind Workflows dafür gut geeignet. Inaktive Workflowinstanzen werden in der Datenbank beibehalten, sodass der Speicher nicht belegt wird.
• Nachverfolgung: WF bietet den Mechanismus zum Nachverfolgen aller in einem Workflow ausgeführten Aktivitäten
• * Visual Designer: Ich stelle dies als * dar, weil ich denke, dass dies wirklich nur für Marketingzwecke nützlich ist. Als Entwickler schreibe ich lieber Code, als Dinge visuell zusammenzufassen. Und wenn Sie einen Nicht-Entwickler haben, der Workflows erstellt, kommt es oft zu einem verwirrenden Durcheinander.

Nachteile

• Programmiermodell: Sie haben wirklich nur eingeschränkte Programmierfunktionen. Denken Sie über all die großartigen Funktionen nach, die Sie in C # haben, und vergessen Sie sie dann nicht. Einfache ein- oder zweizeilige Anweisungen in C # werden zu ziemlich umfangreichen Blockaktivitäten. Dies ist besonders bei der Eingabevalidierung ein Schmerz. Wenn Sie jedoch wirklich darauf achten, nur die Logik auf hoher Ebene in Workflows und alles andere in C # beizubehalten, ist dies möglicherweise kein Problem.
• Leistung: Workflows beanspruchen viel Speicherplatz. Wenn Sie viele Workflows auf einem Server bereitstellen, stellen Sie sicher, dass Sie über eine Menge Arbeitsspeicher 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 die Dinge zum Laufen bringen und den besten Weg finden, etwas zu tun.
• Inkompatibilität der Workflow-Version: Wenn Sie einen Workflow mit Persistenz bereitstellen und Updates für den 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 lässt C # -Ausdrücke zu).
• Nicht flexibel: Wenn Sie spezielle oder spezifische Funktionen benötigen, die von Workflow Foundation nicht bereitgestellt werden, bereiten Sie sich auf eine Menge Schmerzen vor. In einigen Fällen ist dies möglicherweise nicht möglich. Wer weiß bis du es versuchst? Hier besteht ein großes Risiko.
• WCF-XAML-Dienste ohne Schnittstellen: Normalerweise entwickeln Sie mit WCF-Diensten 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, den ich für die Verwendung der Workflow-Grundlagen gefunden habe, ist, wie viel Sie in Bezug auf Nachverfolgung und Beständigkeit aus dem Stand bringen. Es ist sehr einfach, den Persistenzdienst in Betrieb zu nehmen, wodurch Zuverlässigkeit und Lastverteilung zwischen mehreren Instanzen und Hosts erreicht werden.

Auf der anderen Seite, genau wie bei Formular-Apps, sind die Codemuster, auf die Sie der Workflow-Designer drängt, schlecht. Sie können jedoch Probleme vermeiden, indem Sie keinen Code in den Workflow schreiben und die gesamte Arbeit an andere Klassen delegieren, die organisierter und einheitlicher getestet werden als der Workflow. Dann bekommen Sie den coolen visuellen Aspekt des Designers, ohne den Spaghetti-Code hinter sich zu lassen.

Persönlich bin ich nicht bei WF verkauft. Ihre Nützlichkeit war mir nicht so offensichtlich wie andere neue MS-Technologien wie WPF oder WCF.

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

Das Unternehmen, für das ich zurzeit arbeite, hat eine Windows Workflow Foundation (WF) eingerichtet. Die Gründe, aus denen sie sich entschieden haben, waren, dass sich die Regeln häufig ändern würden und dies dazu führen würde, dass die verschiedenen DLLs usw. neu kompiliert werden mussten war, die Regeln in der DB zu platzieren und von dort aufzurufen. Auf diese Weise könnten sie die Regeln ändern und die DLLs usw. nicht neu kompilieren und umverteilen müssen. 

Windows-Workflows verführen nichtcodierende IT-Manager, BAs und dergleichen wie ihr Vetter BizTalk, aber in der Praxis sind Unit-Tests, Debugging und Codeabdeckung nur drei der vielen Fallstricke. Sie können einige von ihnen überwinden, aber Sie müssen viel dafür investieren, während Sie mit reinem Code das nur bekommen. Wenn Sie wirklich eine langfristige Anforderung haben, benötigen Sie wahrscheinlich etwas anspruchsvolleres. Ich habe das Argument gehört, neue XAML-Dateien in der Produktion ablegen zu können, ohne DLLs neu zu kompilieren, aber ehrlich gesagt könnte die Zeit, die Workflows benötigen, besser dazu verwendet werden, die Continuous Integration so zu verbessern, dass kompilierte Bereitstellungen kein Problem darstellen.

Ich würde es in jeder Umgebung einsetzen, in der ich mit Workflow arbeiten muss. Wenn es jedoch in Verbindung mit K2 oder sogar SharePoint 2007 verwendet wird, ist die Leistungsfähigkeit der Plattform wirklich nützlich. Bei der Entwicklung von Geschäftsanwendungen mit BI-Spezialisten wird die Verwendung der Plattform empfohlen. Dies wäre normalerweise nur für die Rationalisierung und Verbesserung der Geschäftsprozesse relevant.

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

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

Ich verwende den Windows-Workflow seit Monaten, um benutzerdefinierte Aktivitäten zu entwickeln, und einen neu gehosteten Designer, den Nicht-Entwickler zum Erstellen von Workflows verwenden können. WF ist sehr mächtig, aber es ist nur so gut wie die benutzerdefinierten Aktivitäten, die von Entwicklern erstellt werden. Im Endeffekt muss ein Entwickler Workflows prüfen, die von Nicht-Entwicklern erstellt wurden, um zu testen und zu debuggen, aber ab dem Punkt, an dem sie Entwurfsworkflows erstellen können, ist das fantastisch.

In Fällen, in denen Prozesse lange ausgeführt werden WF, ist dies ein guter Tech-Stack, wenn Sie Prozesse dynamisch aktualisieren müssen Ihre Architektur sollte mit Versionierung eingerichtet sein, um die alte zu verwerfen und die neue zu verwenden.