Frage

Manche Dinge lassen sich einfacher per Hand (Code) implementieren, andere lassen sich jedoch einfacher über WF implementieren.Es sieht so aus, als ob mit WF (fast) jede Art von Algorithmus erstellt werden kann.Daher kann ich (theoretisch) 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 die Vor- und Nachteile/Kosten von WF vs.Von Hand codieren?

War es hilfreich?

Lösung

Sie können WF brauchen nur, wenn eine der folgenden Bedingungen erfüllt sind:

  1. Sie haben einen lang andauernden Prozess.
  2. Sie haben einen Prozess, der häufig ändert.
  3. Sie wollen ein visuelles Modell des Prozesses.

Weitere Informationen finden Sie Paul Andrews Beitrag: Was für? Windows Workflow Foundation verwenden

Bitte nicht zu verwechseln oder WF beziehen sich mit visueller Programmierung jeglicher Art. Es ist falsch und kann zu sehr schlechte Architektur / Design-Entscheidungen führen.

Andere Tipps

Niemals.Sie werden es wahrscheinlich bereuen:

  • Steile Lernkurve
  • Schwierig zu debuggen
  • Schwierig zu pflegen
  • Bietet nicht genügend Leistung, Flexibilität oder Produktivitätssteigerung, um seinen Einsatz zu rechtfertigen
  • Kann und wird den Anwendungsstatus beschädigen, der nicht wiederhergestellt werden kann

Ich könnte mir nur vorstellen, WF zu verwenden, wenn ich den Designer für einen Endbenutzer hosten möchte, und wahrscheinlich nicht einmal dann.

Vertrauen Sie mir, nichts wird jemals so einfach, leistungsstark oder flexibel sein wie der Code, den Sie schreiben, um genau das zu tun, was Sie von ihm erwarten.Halten Sie sich von WF fern.

Das ist natürlich nur meine Meinung, aber ich finde sie verdammt gut.:) :)

Der Code von WF erzeugt wird, ist böse. Der Wert, den WF bringt, ist in der visuellen Darstellung des Systems, obwohl ich noch etwas (6-7 Projekte bei der Arbeit jetzt mit WF, die ich mit beteiligt haben), um zu sehen, wo ich würde nicht eine einfachere Hand codiert Projekt bevorzugt haben .

In der Regel, wenn Sie die Ausdauer und Tracking-Funktionen nicht benötigen (was meiner Meinung nach sind die wichtigsten Merkmale), sollten Sie nicht Workflow Foundation verwenden.

Hier sind die Vor- und Nachteile der Workflow Foundation ich aus meiner Erfahrung gesammelt:

Vorteile

  • Persistence: Wenn Sie viele lange laufenden Prozesse (man denke Tage, Wochen, Monate) haben werden, dann Workflows sind für diese. Idle Workflow-Instanzen werden in der Datenbank beibehalten, damit es nicht Speicher aufbrauchen.
  • Tracking: WF stellt den Mechanismus jede Aktivität in einem Workflow
  • ausgeführt verfolgen
  • * Visuelle Designer: Ich habe dies als *, weil ich denke, das ist wirklich für Marketing-Zwecke nur dann sinnvoll ist. Als Entwickler, ziehe ich es, Code zu schreiben, anstatt die Dinge zusammen visuell schnappen. Und wenn Sie einen Nicht-Entwickler machen Workflows haben, können Sie oft mit einem riesigen verwirrenden Chaos enden.

Nachteile

  • Programmierung Modell: Sie sind wirklich in Programmierfunktionen beschränkt. Denken Sie an all die großen Features, die Sie in C #, dann über sie vergessen. Einfach ein oder zwei Linien Aussagen in C # wird eine ziemlich große Block-Aktivitäten. Dies ist insbesondere ein Schmerz für Eingabevalidierung. Having said that, wenn Sie wirklich vorsichtig sind nur in Workflows High-Level-Logik zu halten, und alles andere in C #, dann könnte es kein Problem sein.
  • Performance: Workflows verwenden, um eine große Menge an Speicher. Wenn Sie eine Menge von Workflows auf einem Server bereitstellen, stellen Sie sicher, dass Sie jede Menge Speicher. Auch beachten Sie, dass Arbeitsabläufe sind viel langsamer als normal C # -Code.
  • Steile Lernkurve, schwer zu debuggen: Wie bereits oben erwähnt. Du wirst eine Menge Zeit damit verbringen, herauszufinden, wie sie die Dinge zum Laufen zu bringen, und den besten Weg herauszufinden, etwas zu tun.
  • Workflow Version Inkompatibilität: Wenn Sie einen Workflow mit Ausdauer bereitstellen, und Sie müssen Updates für den Workflow machen, die alten Workflow-Instanzen sind nicht mehr kompatibel. Angeblich wird diese in feste .NET 4.5.
  • Sie haben VB Ausdrücke verwenden (.NET 4.5 ermöglicht C # Ausdrücke).
  • Nicht flexibel: Wenn Sie einige spezielle oder bestimmte Funktionen müssen nicht von Workflow Foundation zur Verfügung gestellt, für eine Menge Schmerzen bereiten. In einigen Fällen kann es auch gar nicht möglich sein. Wer weiß, bis Sie versuchen? Es gibt eine Menge von Risiko hier.
  • WCF XAML-Dienste ohne Schnittstellen: Normalerweise mit WCF-Dienste entwickeln Sie gegen eine Schnittstelle. Mit WCF-XAML-Diensten, können Sie nicht ein WCF XAML-Service sicherzustellen, alles in einer Schnittstelle implementiert hat. Sie brauchen nicht einmal eine Schnittstelle zu definieren. (Soweit ich weiß ...)

Der Hauptgrund, warum ich für den Einsatz von Workflow Foundation gefunden habe, ist, wie viel es Sie aus dem Kasten heraus in Bezug auf die Verfolgung und Beharrlichkeit bringt. Es ist sehr einfach, die Persistenzdienst bis zu erhalten und ausgeführt wird, die Zuverlässigkeit und die Lastverteilung zwischen mehreren Instanzen und Hosts bringt.

Auf der anderen Seite, ebenso wie Formen Apps, die Code-Muster, die der Workflow-Designer Sie drückt auf schlecht sind. Aber Sie können Probleme vermeiden, indem sie keinen Code im Workflow zu schreiben und alle Arbeiten an anderen Klassen zu delegieren, die organisiert werden können und als Einheit getestet eleganter als der Workflow. Dann sind Sie den kühlen visuellen Aspekt des Designers bekommen, ohne die cruft von Spaghetti-Code zurück.

Ich persönlich bin auf WF nicht verkauft. Es ist Nutzen für mich als andere neue MS-Technologien wie WPF oder WCF nicht so offensichtlich war.

denke, ich werde WF in Zukunft stark in Business-Anwendungen verwendet werden, aber ich habe nicht die Absicht, es zu benutzen, weil es nicht wie das richtige Werkzeug für den Job für meine Projekte scheint.

Die Firma, die ich zur Zeit für arbeite ein Windows Workflow Foundation (WF) und die Gründe einrichten wählten sie es war zu verwenden, da die Regeln häufig wechselnden werden würde, und das würde sie zwingen, eine erneute Kompilierung der verschiedenen DLL usw. zu tun und so war ihre Lösung der Regeln in der DB zu platzieren und sie von dort anrufen. So können sie die Regeln ändern könnte und nicht neu kompiliert werden müssen und verteilen die DLLs usw.

Windows-Workflows verführen nicht-kodierenden IT-Manager, BAs und dergleichen als sein Vetter BizTalk tut, aber in der Praxis Unit-Tests, Debugging und Code-Coverage sind nur drei der vielen Fallen. Sie können einige von ihnen zu überwinden, aber sie haben stark bei der Erreichung zu investieren, während mit einfachen Code, den Sie nur das bekommen. Wenn Sie wirklich eine lang andauernde Anforderung haben, dann müssen Sie wahrscheinlich etwas raffinierter. Ich habe das Argument gehört, über die Möglichkeit, neue XAML-Dateien in der Produktion ohne erneute Kompilierung dlls fallen, aber ehrlich gesagt die Zeit, die Arbeitsabläufe besser verbrauchen könnte verwendet werden, um Ihre Continuous Integration auf den Punkt zu verbessern, wo zusammengestellt entfaltet kein Problem ist.

ich es in jeder Umgebung verwenden würde, wo ich mit Workflow arbeiten, aber wenn es in Verbindung mit K2 oder sogar Sharepoint 2007 die Leistung der Plattform wirklich nützlich ist. Bei Business-Anwendungen mit BI-Spezialisten entwickelt die Nutzung der Plattform wird empfohlen, und dies würde normalerweise nur relevant sein, zu optimieren und Geschäftsprozesse zu verbessern.

Für die Aufzeichnung WF in Verbindung mit K2-Entwicklungsteam entwickelt wurde und die neue K2 Blackpearl ist oben auf WF gebaut, so ist MOSS 2007 und WSS 3.0 Workflow-Engines.

Wenn Sie nicht wollen, manuell diese Codes alle schreiben, um die visuelle Schnittstelle, Tracking und Ausdauer zu halten, es ist eine kluge Wahl für WF zu wählen.

Ich habe seit Monaten Windows-Workflow unter Verwendung von jetzt benutzerdefinierten Aktivitäten und ein Re-hosted-Designer, die Nicht-Entwickler-Workflows erstellen können zu entwickeln. WF ist sehr leistungsfähig, aber es ist nur so gut wie die individuellen Aktivitäten, die von den Entwicklern gebaut werden. Wenn es bis zu ihm kommt, würde ein Entwickler müssen Workflows durch Nicht-Entwickler gebaut überblicken zu testen und zu debuggen, aber von dem Punkt können sie Entwurf erstellen workflows- dass fantastisch ist.

In Fällen, in denen Sie langen Lauf haben verarbeitet WF ein guter Tech-Stack zu verwenden, wenn Sie Prozesse müssen dynamisch aktualisieren - ohne Neuinstallation auf / Download oder irgendetwas tun, fügen Sie einfach die neuen XAML-Dateien in ein Verzeichnis und Ihre Architektur mit Versionierung einrichten Schrott der alten werden soll, und die neuen.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top