Quand utiliser Windows Workflow Foundation? [fermé]

154

Certaines choses sont plus faciles à implémenter simplement à la main (code), mais certaines le sont via WF. Il semble que WF puisse être utilisé pour créer (presque) n'importe quel type d'algorithme. Donc (théoriquement) je peux faire toute ma logique dans WF, mais c'est probablement une mauvaise idée de le faire pour tous les projets.

Dans quelles situations est-ce une bonne idée d'utiliser WF et quand cela rendra-t-il les choses plus difficiles qu'elles doivent l'être? Quels sont les avantages et les inconvénients / coût de WF par rapport au codage manuel?

Sumrak
la source
3
Il semble intéressant de noter qu'un complètement réécrit pour la version 4.0 qui est sorti après ces réponses.
sclarson

Réponses:

125

Vous pouvez avoir besoin de WF uniquement si l'une des conditions suivantes est vraie:

  1. Vous avez un processus de longue haleine.
  2. Vous avez un processus qui change fréquemment.
  3. Vous voulez un modèle visuel du processus.

Pour plus de détails, consultez l'article de Paul Andrew: Pour quoi utiliser Windows Workflow Foundation?

Veuillez ne pas confondre ou associer WF avec une programmation visuelle de quelque nature que ce soit. C'est faux et peut conduire à de très mauvaises décisions d'architecture / conception.

Panos
la source
4
Quelle est l'unité de mesure pour un processus de longue durée?
ivorykoder
5
@ivorykoder "processus" (vraiment des workflows ) qui peuvent survivre aux redémarrages du serveur qui l'héberge.
homard du
Si j'avais des exigences qui ne satisfaisaient que le n ° 1, ce ne serait pas suffisant pour moi de choisir WF. Cependant, si les exigences incluaient le n ° 2 et / ou le n ° 3, ce serait un cas beaucoup plus fort pour l'utilisation de WF.
Mick le
12
Je ne peux pas résister: vous n'aurez besoin de WF que si l'une des conditions suivantes est vraie: false.
Ronnie Over du
84

Jamais. Vous le regretterez probablement:

  • Une courbe d'apprentissage abrupte
  • Difficile à déboguer
  • Difficile à entretenir
  • Ne fournit pas suffisamment de puissance, de flexibilité ou de gain de productivité pour justifier son utilisation
  • Peut corrompre et corrompra l'état de l'application qui ne peut pas être récupéré

La seule fois où je pourrais concevoir d'utiliser WF, c'est si je voulais héberger le concepteur pour un utilisateur final et probablement même pas à ce moment-là.

Croyez-moi, rien ne sera jamais aussi simple, puissant ou flexible que le code que vous écrivez pour faire exactement ce dont vous avez besoin. Éloignez-vous de WF.

Bien sûr, ce n'est que mon avis, mais je pense que c'est un sacré bon. :)

Ronnie Overby
la source
27
-1 Je respecte votre opinion à ce sujet, mais j'apprécierais beaucoup une explication professionnelle de la raison. Je ne vois pas comment ce genre de réponse aide n'importe qui
danfromisrael
9
J'ai écrit cette réponse un jour où j'étais en colère contre WF4. Je mettrai à jour ma réponse avec les problèmes que j'ai rencontrés.
Ronnie Over du
5
Nous avons hérité d'un projet à moitié achevé d'un consultant qui a utilisé WF comme épine dorsale. Il était sujet aux erreurs, aux flux de travail corrompus qui ne peuvent pas être redémarrés, un système de gestion des versions archaïque qui nécessite une duplication complète du flux de travail pour toute modification mineure, un code généré horrible et un code si délicat que vous devez le gérer avec des gants pour enfants . Après 6 mois d'écrans jaunes de mort, nous avons mis au rebut tout le WF et avons utilisé xml à la place. C'est la meilleure décision que nous n'ayons jamais prise.
Kevin DeVoe
10
La phrase: "Ne fournit pas suffisamment de puissance, de flexibilité ou de gain de productivité pour justifier son utilisation" en dit long pour moi. Merci pour ça.
David Tansey
1
Les haineux doivent expliquer leur haine.
Ronnie Overby
46

Le code généré par WF est méchant. La valeur apportée par WF réside dans la représentation visuelle du système, même si je n'ai encore rien vu (6-7 projets en cours avec WF avec lesquels j'ai été impliqué) où je n'aurais pas préféré un projet codé à la main plus simple .

Craigb
la source
40

En général, si vous n'avez pas besoin des fonctionnalités de persistance et de suivi (qui à mon avis sont les principales fonctionnalités), vous ne devez pas utiliser Workflow Foundation.

Voici les avantages et les inconvénients de Workflow Foundation que j'ai tirés de mon expérience:

Avantages

  • Persistance: si vous allez avoir de nombreux processus de longue durée (pensez à des jours, des semaines, des mois), les workflows sont parfaits pour cela. Les instances de flux de travail inactives sont conservées dans la base de données afin qu'elle n'utilise pas de mémoire.
  • Suivi: WF fournit le mécanisme pour suivre chaque activité exécutée dans un workflow
  • * Concepteur visuel: je mets cela en *, car je pense que cela n'est vraiment utile qu'à des fins de marketing. En tant que développeur, je préfère écrire du code plutôt que de regrouper les choses visuellement. Et lorsque vous avez un non-développeur qui crée des flux de travail, vous vous retrouvez souvent avec un énorme désordre déroutant.

Désavantages

  • Modèle de programmation: vous êtes vraiment limité dans les fonctionnalités de programmation. Pensez à toutes les fonctionnalités intéressantes que vous avez en C #, puis oubliez-les. De simples instructions d'une ou deux lignes en C # deviennent des activités de bloc assez volumineuses. C'est particulièrement pénible pour la validation des entrées. Cela dit, si vous faites vraiment attention à ne conserver que la logique de haut niveau dans les flux de travail, et tout le reste en C #, cela ne pose peut-être pas de problème.
  • Performances: les workflows utilisent une grande quantité de mémoire. Si vous déployez de nombreux workflows sur un serveur, assurez-vous de disposer de tonnes de mémoire. Sachez également que les flux de travail sont beaucoup plus lents que le code C # normal.
  • Courbe d'apprentissage raide, difficile à déboguer: comme mentionné ci-dessus. Vous allez passer beaucoup de temps à trouver comment faire fonctionner les choses et à trouver la meilleure façon de faire quelque chose.
  • Incompatibilité de version de workflow: si vous déployez un workflow avec persistance et que vous devez mettre à jour le workflow, les anciennes instances de workflow ne sont plus compatibles. On suppose que cela est corrigé dans .NET 4.5.
  • Vous devez utiliser des expressions VB (.NET 4.5 autorise les expressions C #).
  • Pas flexible: si vous avez besoin de fonctionnalités spéciales ou spécifiques non fournies par Workflow Foundation, préparez-vous à beaucoup de douleur. Dans certains cas, cela peut même ne pas être possible. Qui sait jusqu'à ce que vous essayiez? Il y a beaucoup de risques ici.
  • Services WCF XAML sans interfaces: normalement avec les services WCF, vous développez par rapport à une interface. Avec les services WCF XAML, vous ne pouvez pas garantir qu'un service WCF XAML a tout mis en œuvre dans une interface. Vous n'avez même pas besoin de définir une interface. (Pour autant que je sache...)
Mas
la source
7
La plupart de vos inconvénients ne sont tout simplement pas vrais, peut-être que vous n'êtes pas assez familier avec WF. WF est très flexible. Il vous permet d'écrire des activités personnalisées (activités de code) que vous pouvez réutiliser dans n'importe quel scénario. C'est à vous d'écrire des activités réutilisables. Imaginez que vous puissiez fournir une interface graphique (application WPF avec Workflow Designer Host) aux consultants en entreprise avec un ensemble d'outils d'activités. Maintenant, ils peuvent changer et réorganiser la logique métier selon leurs besoins et ils n'ont pas besoin de développeurs et même de compiler une nouvelle application.
Sven
3
Imaginez maintenant que les Business Consultants doivent utiliser votre concepteur auto-hébergé, mais sans Intellisense! Soit vous lancez le vôtre, soit vous devez utiliser Visual Studio. Je pense également qu'il sera difficile pour les Business Consultants de même comprendre certains des concepts tels que la compensation, l'annulation, le traitement des exceptions. De plus, toute logique qui est un événement à distance complexe entraînera un flux de travail géant qui deviendra impossible à maintenir (oh, et vous aurez besoin de tonnes de RAM pour modifier de tels flux de travail). Vous avez raison cependant, les activités personnalisées soigneusement conçues offrent une bonne flexibilité.
Mas
27

La principale raison que j'ai trouvée pour utiliser la fondation de flux de travail est à quel point cela vous apporte hors de la boîte en termes de suivi et de persistance. Il est très facile de faire fonctionner le service de persistance, ce qui apporte fiabilité et répartition de la charge entre plusieurs instances et hôtes.

D'un autre côté, tout comme les applications de formulaires, les modèles de code vers lesquels le concepteur de flux de travail vous pousse sont mauvais. Mais vous pouvez éviter les problèmes en n'écrivant aucun code dans le flux de travail et en déléguant tout le travail à d'autres classes, qui peuvent être organisées et testées par unité plus facilement que le flux de travail. Ensuite, vous obtenez l'aspect visuel cool du concepteur sans la cruauté du code spaghetti derrière.

Tegan Mulholland
la source
11

Personnellement, je ne suis pas vendu sur WF. Son utilité n'était pas aussi évidente pour moi que d'autres nouvelles technologies MS, comme WPF ou WCF.

Je pense que WF sera largement utilisé dans les applications d'entreprise à l'avenir, mais je n'ai pas l'intention de l'utiliser car il ne semble pas être le bon outil pour le travail de mes projets.

Rob
la source
7

La société pour laquelle je travaille actuellement a mis en place une Windows Workflow Foundation (WF) et les raisons pour lesquelles ils ont choisi de l'utiliser étaient parce que les règles changeaient fréquemment et cela les obligerait à recompiler les différentes dll, etc. et donc leur solution. était de placer les règles dans la base de données et de les appeler à partir de là. De cette façon, ils pourraient changer les règles et ne pas avoir à recompiler et redistribuer les dll, etc.

rae1
la source
21
Dommage que les applications et services Web réguliers n'aient pas de fichiers .config, ne peuvent pas lire les bases de données, ni lire les fichiers XML ou locaux contenant des règles, sans recompilation. Oh wait ...
Dour High Arch
6

Les flux de travail Windows séduisent les responsables informatiques non codants, les BA et autres, tout comme son cousin BizTalk, mais dans la pratique, les tests unitaires, le débogage et la couverture du code ne sont que trois des nombreux pièges. Vous pouvez surmonter certains d'entre eux, mais vous devez investir massivement pour y parvenir, alors qu'avec un code simple, vous obtenez cela. Si vous avez vraiment un besoin de longue date, vous avez probablement besoin de quelque chose de plus sophistiqué. J'ai entendu l'argument de la possibilité de déposer de nouveaux fichiers xaml en production sans recompiler les dll, mais honnêtement, le temps que les flux de travail consommeront pourrait être mieux utilisé pour améliorer votre intégration continue au point où les déploiements compilés ne sont pas un problème.

Owain Glyndŵr
la source
3

Je l'utiliserais dans n'importe quel environnement où je dois travailler avec un flux de travail, mais lorsque je l'utilise en conjonction avec K2 ou même SharePoint 2007, la puissance de la plate-forme est vraiment utile. Lors du développement d'applications métier avec un spécialiste BI, l'utilisation de la plate-forme est recommandée et cela ne serait normalement pertinent que pour rationaliser et améliorer les processus métier.

Pour mémoire, WF a été développé en collaboration avec l'équipe de développement de K2 et le nouveau K2 Blackpearl est construit sur WF, tout comme les moteurs de flux de travail de MOSS 2007 et WSS 3.0.

BinaryMisfit
la source
2

Lorsque vous ne voulez pas écrire manuellement tous ces codes pour maintenir l'interface visuelle, le suivi et la persistance, c'est un choix judicieux de voter pour WF.

étincelles
la source
1

J'utilise le flux de travail Windows depuis des mois maintenant pour développer des activités personnalisées et un concepteur réhébergé que les non-développeurs peuvent utiliser pour créer des flux de travail. WF est très puissant, mais il est aussi bon que les activités personnalisées créées par les développeurs. En fin de compte, un développeur devrait examiner les flux de travail créés par des non-développeurs pour tester et déboguer, mais à partir du moment où ils peuvent créer des projets de flux de travail, c'est fantastique.

De plus, dans les cas où vous avez des processus de longue durée, WF est une bonne pile technologique à utiliser lorsque vous devez mettre à jour des processus de manière dynamique - sans avoir à réinstaller / télécharger ou faire quoi que ce soit, ajoutez simplement les nouveaux fichiers XAML à un répertoire et votre architecture devrait être mis en place avec la gestion des versions pour supprimer l'ancien et utiliser le nouveau.

JohnChris
la source