Quand utiliser Windows Workflow Foundation? [fermé]

Question

Certaines choses sont plus faciles à mettre en œuvre simplement à la main (code), mais certaines sont plus faciles grâce à 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 en 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 est-ce que cela rendra les choses plus difficiles alors qu'elles doivent l'être? Quels sont les avantages et les inconvénients / le coût de la WF par rapport au codage à la main?

Answer 1

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

1. Votre processus est long.
2. Votre processus change fréquemment.
3. Vous voulez un modèle visuel du processus.

Pour plus de détails, voir le message de Paul Andrew: Pourquoi utiliser Windows Workflow Foundation?

Ne confondez pas et n’associez pas le WF à une programmation visuelle quelconque. C'est faux et cela peut conduire à de très mauvaises décisions d'architecture / conception.

Answer 2

Jamais. Vous le regretterez probablement:

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

La seule fois où j'ai pu imaginer utiliser WF, c’est si je souhaitais héberger le concepteur pour un utilisateur final et probablement même pas à ce moment-là.

Faites-moi confiance, 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 opinion, mais je pense que c’est une très bonne. :)

Answer 3

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 auxquels je participe) pour laquelle je n’aurais pas préféré un projet codé à la main plus simple. .

Answer 4

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

Voici les avantages et les inconvénients de Workflow Foundation que je tire de mon expérience:

Avantages

• Persistance: si vous envisagez de nombreux processus longs (plusieurs jours, semaines, 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 ne consomme pas de mémoire.
• Suivi: WF fournit le mécanisme permettant de suivre chaque activité exécutée dans un flux de travail
• * Concepteur visuel: Je mets ceci comme un *, parce que je pense que ce n’est vraiment utile que dans un but marketing. En tant que développeur, je préfère écrire du code plutôt que de combiner visuellement des éléments. Et lorsque vous avez un flux de travail non-développeur, vous vous retrouvez souvent avec un énorme désordre déroutant.

Inconvénients

• Modèle de programmation: Les fonctionnalités de programmation sont vraiment limitées. Pensez à toutes les fonctionnalités intéressantes de C #, puis oubliez-les. Les déclarations simples à une ou deux lignes en C # deviennent des activités de bloc assez volumineuses. Ceci est particulièrement pénible pour la validation des entrées. Cela dit, si vous veillez à ne conserver que la logique de haut niveau dans les flux de travail et tout le reste en C #, il se peut que ce ne soit pas un problème.
• Performances: les workflows utilisent une grande quantité de mémoire. Si vous déployez de nombreux flux de travail sur un serveur, assurez-vous de disposer de beaucoup de mémoire. Sachez également que les workflows sont beaucoup plus lents que le code C # normal.
• Courbe d'apprentissage abrupte, difficile à déboguer: comme mentionné ci-dessus. Vous allez passer beaucoup de temps à chercher comment faire fonctionner les choses et à trouver le meilleur moyen de faire quelque chose.
• Incompatibilité de la version du flux de travail: si vous déployez un flux de travail avec persistance et que vous devez apporter des mises à jour au flux de travail, les anciennes instances de flux de travail ne sont plus compatibles. Soi-disant, 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 à vivre une vie difficile. Dans certains cas, cela pourrait même ne pas être possible. Qui sait jusqu'à ce que vous essayiez? Il y a beaucoup de risques ici.
• Services XAML WCF sans interface: Normalement, avec les services WCF, vous développez une interface. Avec les services XAML WCF, vous ne pouvez pas garantir qu'un service XAML WCF a tout mis en œuvre dans une interface. Vous n'avez même pas besoin de définir une interface. (autant que je sache ...)

Answer 5

La principale raison pour laquelle j'ai trouvé l'utilisation de la base de processus de travail est son apport en termes de suivi et de persistance. Il est très facile de mettre en place le service de persistance, ce qui apporte fiabilité et répartition de la charge entre plusieurs instances et hôtes.

D'autre part, tout comme les applications de formulaires, les modèles de code vers lesquels le concepteur de flux de travail vous pousse sont incorrects. 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 harmonieusement que le flux de travail. Ensuite, vous obtenez l'aspect visuel cool du concepteur sans le fouillis de code spaghetti derrière.

Answer 6

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

Je pense que WF sera largement utilisé dans les applications métier à l'avenir, mais je n'envisage pas de l'utiliser, car cela ne semble pas être le bon outil pour mes projets.

Answer 7

La société pour laquelle je travaille actuellement a configuré Windows Workflow Foundation (WF) et a choisi de l'utiliser car les règles étaient fréquemment modifiées et cela les obligeait à recompiler les différentes dll, etc. leur solution a donc été 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 sans avoir à recompiler et à redistribuer les DLL, etc.

Answer 8

Les workflows Windows séduisent les directeurs informatiques, les BA et autres utilisateurs non codés, tout comme son cousin BizTalk, mais dans la pratique, les tests unitaires, le débogage et la couverture de code ne sont que trois des nombreux pièges. Vous pouvez en surmonter certaines, mais vous devez investir énormément pour y parvenir, alors qu'avec un code simple, vous l'obtenez. Si vous avez véritablement une exigence de longue durée, vous avez probablement besoin de quelque chose de plus sophistiqué. J'ai entendu parler de la possibilité de déposer de nouveaux fichiers xaml en production sans re-compiler des dll, mais honnêtement, le temps que les workflows vont consommer pourrait être mieux utilisé pour améliorer votre intégration continue au point que les déploiements compilés ne posent plus de problème.

Answer 9

Je l’utiliserais dans n’importe quel environnement où je devrais travailler avec un flux de travail. Cependant, lorsqu’il est utilisé en conjonction avec K2 ou même avec SharePoint 2007, la puissance de la plate-forme est vraiment utile. Lors du développement d'applications métier avec un spécialiste en BI, l'utilisation de la plate-forme est recommandée. Cela ne devrait normalement servir qu'à 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, de même que les moteurs de flux de travail MOSS 2007 et WSS 3.0.

Answer 10

Lorsque vous ne souhaitez pas écrire manuellement tous ces codes pour conserver l'interface visuelle, le suivi et la persistance, il est judicieux de voter pour WF.

Answer 11

J'utilise le flux de travail Windows depuis des mois pour développer des activités personnalisées et un concepteur hébergé à nouveau que les non-développeurs peuvent utiliser pour créer des flux de travail. WF est très puissant, mais il n’est à la hauteur que des 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 le tester et le déboguer, mais il peut créer des brouillons, ce qui est fantastique.

De plus, dans le cas de longs processus en cours, WF est une bonne pile technologique à utiliser lorsque vous devez mettre à jour les processus de manière dynamique - sans avoir à réinstaller / télécharger ni faire quoi que ce soit, ajoutez simplement les nouveaux fichiers XAML à un répertoire et vos fichiers. L’architecture doit être configurée avec la gestion des versions pour supprimer l’ancienne et utiliser la nouvelle.