Windows Workflow Foundation
Suite à la présentation de la Windows Workflow Foundation, lors des rencontres du Dot User Group (où nous étions assez peu, je suis surpris de ne pas voir plus de monde à un événement gratuit et intéressant), je me pose des questions sur la Windows Workflow Foundation. Et comme convenu lors de la rencontre, je pose ces questions sur ce forum.
Nous avons vu une présentation d’un workflow séquentiel. J’en suis resté un peu perplexe, car j’ai eu l’impression de me retrouver face à une programmation plus procédurale qu’objet. Il m’a semblé que le workflow est un objet composé d’un ensemble d’étapes (de code, spécifiquement descendant de la classe Activity pour l’essentiel), qui traitent des données, un document, par exemple.
Par exemple, on fait un test, si le résultat est vrai on passe à l’activité 1 sinon à l’activité 2, et ces activités font progresser le document dans le workflow. Dans les objets de classe Activity, on peut effectivement faire appel à es objets extérieurs, mais comme le faisait remarquer un participant, un peu comme on ferait appel à des fonctions d’une DLL. Là aussi, cela ne m’a pas semblé être très philosophie objet. J’ai vraiment l’impression que l’on a d’un côté du code (le workflow, ses tests et ses activités) et d’un autre les données (le document qui suit le workflow, par exemple).
Il s’avère que mon projet actuel traite de gestions de documents, dans un cadre clients serveur. On numérise divers types de documents, et les fichiers numérisés vont servir à divers traitement automatiques (comme de l’OCR ou des vérifications) et à divers traitement manuels (de la saisie et des contrôles). Il s’agit bien de workflow. Enfin, de plusieurs workflows, l’application peut aussi bien traiter la saisie des chèques pour une banque que des formulaires complexes avec pièces jointes pour la même banque ou un autre client.
Le modèle objet est… résolument objet. Les entités métiers coopèrent avec les entités de configuration client pour savoir quel workflow elles ont à suivre, et à chaque étape, en utilisant par exemple des Design Patterns comme State ou Strategy, les objets métiers de type document ou collection de document savent ce qu’ils ont à faire (à quelle étape de leur propre workflow ils en sont) et avec qui le faire (avec quel type de client).
Je ne vais pas détailler plus le système, mais on peut faire l’analogie avec un système multi-agents, où chaque document ou collection de documents coopère avec d’autres objets métiers pour savoir quoi faire, selon son état.
Je ne sais pas si je suis clair, mais j’essaie de faire passer le point suivant : dans la présentation que j’ai vue, la responsabilité des traitements était dans les objets activity, et dans l’objet workflow lui-même, le cadre général qui donne le chemin des diverses activités. Les documents (le data du workflow) avaient un rôle passif. Dans le modèle objet de mon application, les documents ne sont pas de simple data. Ils contiennent le code qui leur permet d’agir avec un client automatique ou manuel, ce sont de véritables objets métiers (même s’ils changent ce code à la volée, selon leurs états et leurs paramétrages).
Dans ce modèle, il n’y a pas vraiment d’objet workflow qui soit instancié et qui agisse sur les documents. Ce sont les documents qui contiennent les règles métiers, et qui les exécutent dans le cadre de d’applications clientes.
Du coup, j’ai l’impression, quand je regarde la Windows Workflow Foundation, qu’elle n’est pas adaptée à ce que je suis en train de faire.
Mais j’ai peut être tort. D’abord, on a juste effleuré la surface. Ensuite, Dot Net est un magnifique framework, totalement objet et qui témoigne d’une grande maîtrise de l’orienté objet. Je me dis donc que je dois louper quelque chose quelque part.
Des commentaires?
Richard
Répondre avec citation
Envoyé par Promeneur
.
Partager