Quand utiliser Windows Workflow Foundation?

Question

Certaines choses sont plus faciles à implémenter simplement à la main (code), mais certaines sont plus faciles grâce à WF. WF peut ê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 va-t-il rendre les choses plus difficiles alors qu'elles doivent l'être? Quels sont les avantages et les inconvénients / coût du WF par rapport au codage manuel?

Answer 1

Vous pouvez avoir besoin WF seulement si les conditions suivantes sont remplies:

1. Vous avez un long processus en cours d'exécution.
2. Vous avez un processus qui change fréquemment.
3. Vous souhaitez un modèle visuel du processus.

Pour plus de détails, voir Paul-André post: Ce que l'utilisation de Windows Workflow Foundation?

Merci de ne pas confondre ou se rapportent WF avec visual programmation de tout genre. Il est erroné et peut conduire à de très mauvais architecture/design décisions.

Answer 2

Jamais. Vous allez probablement le regretter.

Pourquoi? Simple,

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

Le seul moment où je pourrais jamais concevoir de l'aide WF est si je voulais accueillir le designer pour un utilisateur final, et probablement même pas alors.

Croyez-moi, rien ne sera jamais aussi simple, puissant, ou souple que le code que vous écrivez pour faire exactement ce dont vous avez besoin. Rester à l'écart de WF.

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

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 actuellement avec WF avec lesquels j'ai été impliqué) où 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 de la persistance et de fonctionnalités de suivi (qui à mon avis sont les principales caractéristiques de), vous ne devriez pas utiliser un Workflow Foundation.

Ici sont les avantages et les inconvénients de Flux de travail de la Fondation que j'ai recueillies à partir de mon expérience:

Avantages

• Persistance: Si vous allez avoir de nombreux processus en cours d'exécution (pensez à des jours, des semaines, des mois), puis les flux de travail sont parfaits pour cela. Inactif instances de flux de travail sont conservées dans la base de données n'a donc pas d'utilisation de la mémoire.
• Suivi de: WF fournit le mécanisme pour assurer le suivi de chaque activité exécutée dans un flux de travail
• *Concepteur visuel: j'ai mis cela comme un *, parce que je pense que c'est vraiment utile uniquement pour des fins de marketing. En tant que développeur, je préfère écrire du code plutôt que de claquer des choses visuellement. Et quand vous avez un non-développeur décisionnel des flux de travail, vous finissent souvent avec un énorme désordre déroutant.

Inconvénients

• Modèle de programmation: Vous êtes vraiment limité dans les fonctionnalités de programmation. Pensez à toutes les fonctionnalités que vous avez dans le C#, puis de les oublier. Simple une ou deux ligne de déclarations en C# devient un assez grand bloc d'activités. C'est en particulier une douleur pour la validation d'entrée. Cela dit, si vous êtes très prudent pour ne garder que de haut niveau de la logique dans les flux de travail, et tout le reste en C#, alors il pourrait ne pas être un problème.
• Performance: les flux de travail utilise une grande quantité de mémoire. Si vous déployez beaucoup de flux de travail sur un serveur, assurez-vous que vous avez des tonnes de mémoire. Sachez également que les flux de travail sont beaucoup plus lent que la normale de code C#.
• Courbe d'apprentissage très raide, difficile à déboguer: Comme mentionné ci-dessus. Vous allez passer beaucoup de temps à essayer de comprendre comment obtenir les choses, et de déterminer la meilleure façon de faire quelque chose.
• Flux de travail Version Incompatibilité: Si vous déployez un flux de travail avec de la persévérance, et vous avez besoin de mettre à jour le flux de travail, les anciennes instances de flux de travail ne sont plus compatibles. Soi-disant que ce n'est fixé .NET 4.5.
• Vous devez utiliser VB expressions.NET 4.5 permet pour les expressions C#).
• Non flexible: Si vous avez besoin de quelques particuliers ou des fonctionnalités spécifiques ne sont pas fournis par Workflow Foundation, préparer beaucoup de douleur. Dans certains cas, il pourrait même ne pas être possible. Qui sait jusqu'à ce que vous essayez? Il y a beaucoup de risque ici.
• WCF XAML services sans interfaces: Normalement avec les services WCF, vous développer à l'encontre d'une interface. Avec WCF XAML Services, vous ne pouvez pas assurer un WCF XAML Service a mis en place le tout dans une interface. Vous n'avez même pas besoin de définir une interface. (autant que je sache...)

Answer 5

La principale raison que j'ai trouvé à l'aide de flux de travail de la fondation est de savoir combien il vous apporte de la zone en termes de suivi et de persistance. Il est très facile d'obtenir de la persistance de service et en cours d'exécution, ce qui apporte de la fiabilité et de répartition de charge entre plusieurs instances et des hôtes.

Sur l'autre main, tout comme les formes les applications, les modèles de code que le concepteur de flux de travail vous pousse vers sont mauvais. Mais vous pouvez éviter les problèmes par la rédaction pas de code dans le flux de travail et de déléguer tout le travail pour les autres classes, qui peuvent être organisés et de l'unité testée avec plus de grâce que le flux de travail. Ensuite, vous obtenez les frais de l'aspect visuel du concepteur, sans les trucs de code spaghetti derrière.