Introduction
À l'aide de WWF, vous pouvez créer des flux de travail basés sur Processor Flow et les déployer dans n'importe quel type d'application .NET. En outre, cet article aborde certains problèmes uniques rencontrés par les développeurs ASP.NET : problèmes qui peuvent être résolus grâce à l'utilisation de flux de travail, tels que la maintenance de l'état et la navigation dans les pages.
En septembre 2005, Microsoft a dévoilé Windows Workflow Foundation (WWF, Windows Workflow Foundation) lors de sa conférence semestrielle des développeurs professionnels. En tant que l'un des piliers de l'API WinFX, WWF fournit aux développeurs un cadre commun sur lequel développer des applications axées sur les processus et centrées sur les flux de travail.
Actuellement, certaines organisations tentent d'automatiser des processus métier entiers ; leur réponse standard consiste à réunir une équipe de développeurs pour développer le code correspondant. Bien que cette approche fonctionne bien pour ces organisations, elle présente certains problèmes inhérents. Afin de comprendre ce problème en profondeur, vous devez comprendre les caractéristiques de base d’un flux de travail.
Un flux de travail est essentiellement une méthode d'archivage des activités impliquées dans la réalisation d'une unité de travail. Généralement, pendant le traitement, le travail « passe » par une ou plusieurs activités. Ces activités peuvent être effectuées par des machines ou des humains et peuvent être aussi simples que la définition de l'ordre des pages dans une application Internet, ou aussi complexes que la gestion d'un document ou d'un produit qui doit être vu, modifié et approuvé par un nombre illimité de personnes. complexe.
Étant donné que de nombreux flux de travail doivent permettre une implication humaine, leur exécution peut prendre beaucoup de temps, allant de quelques heures à plusieurs mois, voire plus. Par exemple, les personnes impliquées dans le processus peuvent ne pas être disponibles, ne sont pas locales ou sont occupées par d'autres tâches ; le flux de travail doit donc pouvoir persister pendant toutes les périodes d'inactivité ; De plus, les processus mis en œuvre de manière indépendante via le codage peuvent être difficiles à comprendre pour les personnes non techniques et difficiles à modifier pour les développeurs. Ceci et d'autres facteurs sont exactement l'objectif des frameworks de workflow génériques tels que Windows WF - qui visent à faciliter la création, la modification et la gestion des workflows - soit en leur fournissant une interface visuelle, soit en définissant un ensemble commun d'API réalisées.
Vous pouvez placer des flux de travail WWF dans n'importe quel type d'application .NET, y compris Windows Forms, les applications console, les services Windows et les applications Web ASP.NET. Chaque type nécessite des considérations spécialisées. Bien que quelques exemples existants suffisent à illustrer comment héberger des workflows dans Windows Forms et des applications console, cet article se concentrera sur les problèmes rencontrés par les développeurs ASP.NET qui souhaitent intégrer des workflows dans leurs propres applications.
Note de l'auteur : le code fourni dans cet article a été créé à l'aide de Windows WF Beta 1 et Visual Studio 2005 Beta 2. Vous pouvez trouver des informations sur l'installation de Windows WF sur www.windowsworkflow.net . Bien que cet article traite de certaines bases de Windows WF, d'autres ressources sont disponibles dans ce domaine. Je suppose que le lecteur connaît au moins un peu Windows WF. Le but de cet article est d’analyser Windows WF et ASP.NET en profondeur, plutôt que de discuter de Windows WF à un niveau élevé.
1. Modèles Windows WF et MVC
Lors du développement d'une application ASP.NET, une manière courante d'utiliser WWF consiste à implémenter une approche modèle-vue-contrôleur (MVC). Essentiellement, l'objectif de MVC est de séparer la couche de présentation, la logique d'application et la logique de flux d'application.
Comprendre cela sera très bénéfique lors du développement d’une application ASP.NET, veuillez envisager un lieu de flux de travail de ticket d’assistance. Supposons qu'un utilisateur professionnel lance ce flux de travail en remplissant un formulaire Web ASP.NET et en cliquant sur un bouton d'envoi. Ensuite, le serveur informe un employé à l'aide d'une application Windows Forms et du service d'assistance qu'« un nouveau ticket est disponible ». L’employé du service d’assistance travaillera ensuite sur le problème et clôturera enfin le ticket. Si vous utilisez Windows WF pour développer ce scénario de flux de travail, toute la logique et le flux de traitement peuvent être contenus dans le flux de travail lui-même, et l'application ASP.NET n'aura pas du tout besoin de comprendre cette logique.
Ce type de lieu fournit des preuves solides : séparer la description de la logique est une bonne chose. Étant donné que ce processus de traitement des demandes d'assistance est si banal, si vous utilisez du code C# ou VB.NET pour implémenter cette logique dans plusieurs applications .NET différentes, vous courez le risque de dupliquer le codage ou pire, d'utiliser des pistes de code complètement différentes. à différentes implémentations du même processus métier. Mais si vous utilisez WWF pour implémenter ce processus, les développeurs d'applications qui ont besoin de ce processus n'auront qu'à modifier les étapes en un seul endroit - le flux de travail lui-même - sans avoir à se soucier de modifier la logique de l'application. La duplication de code et l'endroit où implémenter ce processus peuvent être facilités grâce à l'utilisation de Windows WF.
Lors de l'implémentation d'une architecture MVC dans ASP.NET à l'aide de Windows WF, les développeurs doivent essayer de créer des flux de travail indépendants de l'application, alors que le flux de travail est toujours hébergé dans l'application. Cela permettra de garder la logique indépendante de la description et de maintenir un degré élevé d'indépendance entre la séquence des étapes de travail et le flux des pages dans l'application Web.
Un nouveau développeur WWF peut essayer de développer un flux de travail avec un nombre fixe d'activités dans un certain ordre, puis développer un ensemble de formulaires Web ASP.NET qui passent d'un formulaire à un autre dans le même ordre. Malheureusement, même si cela semble logique, cela s'avère en réalité très improductif car vous devrez à nouveau implémenter la logique du workflow. La page Web X n'a pas besoin de savoir si elle doit accéder à la page Y ou à la page Z pour implémenter correctement cette étape du flux de travail. Au lieu de cela, le flux de travail (modèle) doit indiquer à ASP.NET (le contrôleur) quoi faire ensuite ; ASP.NET doit alors décider quelle page afficher. De cette façon, chaque page a à peine besoin de comprendre l'ensemble du processus ; il lui suffit de savoir comment effectuer une activité différente et de laisser le flux de travail s'occuper de la façon dont la page circule d'un endroit à un autre. Cette séparation donne aux développeurs une grande flexibilité dans la gestion du flux des pages. Par exemple, si vous décidez de modifier l'ordre dans lequel les pages sont affichées, vous pouvez facilement le faire depuis le flux de travail sans modifier une seule ligne de code dans l'application ASP.NET.
2. Un exemple simple de workflow MVC
Afin d'illustrer cette idée, je vais vous montrer une application et un workflow ASP.NET simples. Ce flux de travail simplifié à l'extrême décrit un processus qui collecte certaines informations privées à partir d'une application externe, puis les affiche. Les étapes sont les suivantes :
1. Invoquer une méthode - cela signifie demander le nom d'une personne ; ce workflow utilise l'activité InvokeMethod (voir Figure 1).
2. Attendez qu'un événement soit déclenché - cela signifie recevoir un nom ; dans cette étape, le workflow utilise l'activité EventSink.
3. Obtenez une adresse e-mail auprès de l'hôte en utilisant un appel similaire.
4. Attendre un événement, c'est recevoir une adresse.
5. Après avoir reçu le nom et l'e-mail, le workflow démarre une activité InvokeMethod pour envoyer les informations personnelles à l'application appelante. Dans une situation réelle, cette dernière étape n’est pas très importante. Plus probablement, vous appellerez un service Web pour envoyer les données à un autre système ou les placerez dans une base de données.
