Question

J'ai lutté si longtemps pour trouver un cas d'utilisation convaincante pour flux de travail (ex: WF) contre la programmation impérative régulière. Chaque fois que je retombe à la conclusion que je devrais laisser WF ou à différer d'entrer dans ce que plus tard. Mais je continue à avoir ce sentiment lancinant qu'il ya quelque chose me manque.

Quelqu'un sait-il un livre qui fait vraiment un cas solide pour la voie de workflow? Le livre doit (i) enseigner WF bien, et (ii) montrent l'utilisation des cas d'utilisation appropriés WF fait une mise en œuvre facile à faire que si nous venons de faire notre codage régulier droit.

Je l'apprécierai.

Était-ce utile?

La solution

Du point de vue d'un non-expert, il y a deux choses qui me font le cas pour WF -. Un unique flux de travail des plates-formes, l'autre peut-être plus d'une chose de commodité

La fonction pratique est la possibilité de créer de nouvelles façons de composer des activités. la programmation Impératif ne fournit qu'un répertoire limité de primitives de composition: essentiellement le séquençage, if-else et des boucles. WF vous permet de créer vos propres opérateurs de composition tels que l'exécution entrelacée, exécution en parallèle, d'abord passé le poste, etc. Et bien sûr, il a le mécanisme de composition sophistiquée des machines d'état intégrées.

Je dis cela est une fonctionnalité pratique parce que vous pouvez construire tous ces opérateurs dans un langage impératif comme C #: en fait qui est comment vous bâtissez les opérateurs WF. Mais WF rend facile à utiliser et lire compositions personnalisées, alors que dans C # vous voulez rapidement aller dans une grêle d'expressions lambda. Donc, si vous avez des exigences d'orchestration complexes - qui est, si la façon dont vos activités emboîtent est plus complexe que les séquences, if-else et boucles -. Puis WF peut rendre votre programme plus facile à exprimer et à comprendre

La caractéristique unique est durabilité . C'est là le livre Shukla et Schmidt commence, et où il revient sans cesse. Un programme impératif écrit en C # ou VB peut fonctionner pendant des heures, des jours, des semaines si elle a de la chance, peut-être même des mois ... mais finalement IIS va cycle de la piscine d'application, ou les admins vont vouloir installer les dernières mises à jour de sécurité ou quelqu'un va trébucher sur le cordon d'alimentation. Comment donc votre programme se souvient: « D'accord, j'ai l'ordre d'achat de la société R Names imaginatif nous, et je suis en attente d'une approbation de crédit de la Banque de Breadheads Inc., et quand je reçois que je peux envoyer la confirmation e-mail "?

Dans un programme classique impératif, lorsque le processus meurt, l'état d'exécution meurt avec elle. Vous pouvez commencer un nouveau processus, mais il commencera au début du programme. Bien sûr, vous pouvez créer une base de données et l'utiliser pour des drapeaux de magasin comme « a obtenu un bon de commande » et « obtenu l'approbation de crédit. » Mais maintenant, vous devez écrire du code spécifique à l'application pour enregistrer et interroger l'état, et de revenir en arrière au point droit dans le programme en fonction de cet état. Et vous devez concevoir une nouvelle base de données et système de sauvegarde / restauration / saut logique pour chaque application unique de longue durée.

Flux de production durable est de résoudre ce problème. Si vous écrivez votre programme en tant que flux d'activités, puis WF prendra soin de son état persistant et notamment lorsqu'il est dans son flux d'exécution. La machine qui exécute le programme peut prendre feu et brûler votre centre de données, mais lorsque la réponse de la banque arrive, WF réveillera votre programme dans l'autre centre de données, et il commencera à fonctionner au bon endroit et le droit données.

Que pour moi est le « cas fort » pour WF. Dans de nombreux cas, vous n'avez pas besoin: les applications sont suffisamment courte durée que l'échec est pas une préoccupation importante, et le redémarrage à partir de zéro est une stratégie de rétablissement viable. Mais pour les applications à long terme, par exemple lorsque vous pouvez les systèmes externes orchestrant qui peuvent prendre des heures pour répondre, ou des processus d'affaires qui impliquent des êtres humains qui peuvent prendre des jours à responsab, la durabilité peut être la fonction de tueur pour WF.

Disclaimer: Je ne suis pas un programmeur WF et ne l'ai jamais construit un monde réel système WF. Je viens à ce à partir d'un fond de BizTalk et de ce que j'ai lu WF, cette évaluation est un peu théorique. Hope it helps tout de même!

Autres conseils

Je ne sais pas s'il y a une bonne réponse à votre question. Le problème est que la question n'est pas valide ou quelque chose comme ça parce que vous demandez deux choses très différentes.

D'abord tout ce que vous demandez pour des raisons impérieuses d'utiliser workflow. Ceci est une question très subjective et non la technologie liée à tous. Vous pouvez trouver des livres blancs sur le web pointant vers toutes sortes de succès, et sans succès pour cette question, les mises en œuvre de flux de travail. Et ce, indépendamment de la technologie, une solution qui a été fait en utilisant un certain X produit pourrait tout aussi bien avoir été fait en utilisant le produit Y. Le chapitre de Shukla et Schmidt explique certainement les fondamentaux mais je ne suis pas sûr que c'est un bon livre vous montrant où et comment appliquer flux de travail.

Deuxièmement, vous êtes à la recherche d'un livre pour vous enseigner Windows Workflow Foundation. La première question est WF3 ou WF4 comme ce sont des bêtes très différentes. Je suppose WF4 parce que cela va remplacer WF3 lorsque .NET 4 est libéré (très bientôt maintenant) et en commençant par WF3 ne fait pas beaucoup de sens dans la plupart des cas. Mais comme WF3 n'a jamais été très populair et le marché du livre pas très rentable pour la plupart des écrivains, il n'y a pas de livres WF4 encore sorti. Je crois que Bruce Bukovics travaille sur une nouvelle version de son Pro WF: Windows Workflow .NET 3.5 livre que j'ai trouvé un des livres de WF3 plus utilisables. Jusqu'à présent, il n'y a rien que vous êtes coincé avec le, extrêmement limité, docs sur le site msdn et blog comme le mien ici . Et bien sûr, il y a des cours là-bas comme cette de DevelopMentor (note: prise sans vergogne que je suis l'auteur du cours principal)

J'ai fourni un certain nombre de raisons dans cette réponse , ceux-ci pourraient vous aider un peu.

Pas tout à fait une réponse à vous la question, mais j'espère que tout cela sera toujours utile pour vous.

est pas non plus une réponse directe, mais cela pourrait être utile si la recherche d'autres ressources. Pour moi, il ressemble à WF est assez étroitement calqué autour des concepts introduits dans Langue d'exécution des processus métier (BPEL) . Ce std. a été autour pour beaucoup plus longtemps que WF, et toute utilisation de BPEL devrait vous donner une idée de ce qu'il faut utiliser pour WF.

Je n'ai pas utilisé WF, mais quand je jouai autour avec BPEL un peu, et je l'ai trouvé difficile à utiliser. Cela est principalement dû au support d'outil (j'ai trouvé le plugin Eclipse pour la modélisation visuelle faisait défaut). Lorsque vous combinez cela avec le fait qu'il est difficile de lire le code XML par rapport à « la syntaxe du langage de programmation normale », alors BPEL était pas une solution viable. Si WF a un bon outil visuel, ce problème a au moins été résolu.

Les bonnes raisons sont les suivantes: Overwiew visuelle de vos processus d'affaires. Vous pouvez même avoir votre client - l'expert de domaine - modifier le flux de travail avec le concepteur; redémarrez l'application et l'ont en cours d'exécution sans recompilation

Bon livre: Bruce Bukowics ET mon AllWays préféré: PRO C # 2010 et le cadre .NET 4 est un excellent chapitre

Je ne sais pas d'un livre spécifique sur ce sujet. Cependant, je crois qu'une partie de l'appel de WF (ou d'autres produits de flux de travail) est qu'il réintroduit la possibilité du paradigme, à base de messages à couplage lâche que les gars OO originaux (comme Alan Kay) étaient intéressés.

Le concept d'un « message » étant passé est pas évident dans WF. Cependant, la notion d'objets agissant comme machines discrètes est.

Pour un livre génial (mais un peu fou) sur l'état de OO, voir objet penser par David Ouest . Et voir pour la discussion d'Alan Kay de ce que signifie pour lui OO .

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top