Cet article vous présentera les applications associées de Windows Workflow 4.0 dans Visual Studio 2010. J'espère que ce court article pourra vous aider à développer Workflow 4.0.
Visual Studio 2010 récemment installé sur une machine virtuelle. L'interface est WPF et l'utilisation du processeur et de la mémoire n'est pas exagérée. Lorsque vous ouvrez un projet de laboratoire attaché très simple, l'utilisation du processeur est généralement inférieure à 20 % et l'utilisation de la mémoire est inférieure à 800 Mo.
Plus près de chez nous, présentons Windows Workflow 4.0.
Le modèle de workflow a beaucoup changé par rapport à la version 3.5.
Nous savons que les workflows de la version 3.5 sont hébergés dans WorkflowRuntime et que les instances de workflow sont créées et exécutées via WorkflowRuntime ; il n'y a pas de classe WorkflowRuntime dans la version 4.0, vous pouvez donc facilement créer des instances WorkflowInstance et exécuter des workflows directement. Le code dans Lab est le suivant :
WorkflowInstance monInstance = nouveau WorkflowInstance(nouveau SayHello(),
new SayHelloInArgs (nom d'utilisateur));
myInstance.OnCompleted = délégué (WorkflowCompletedEventArgs e)
{
Console.WriteLine("*** Le délégué OnCompleted s'exécute sur le thread {0} ***",
Thread.CurrentThread.ManagedThreadId);
SayHelloOutArgs outArgs = new SayHelloOutArgs(e.Outputs);
salutation = outArgs.Greeting;
syncEvent.Set();
} ;
myInstance.OnUnhandledException = délégué (WorkflowUnhandledExceptionEventArgs e)
{
Console.WriteLine(e.UnhandledException.ToString());
retourner UnhandledExceptionAction.Terminate ;
} ;
myInstance.OnAborted = délégué (WorkflowAbortedEventArgs e)
{
Console.WriteLine(e.Reason);
syncEvent.Set();
} ;
monInstance.Run();
Il existe une classe WorkflowInvoker dans la version 4.0. Cette classe peut également exécuter des workflows, mais cette classe est utilisée pour tester les workflows. Cela améliore considérablement la difficulté de tester les workflows dans la version précédente.
[Méthode de test]
public void ShouldReturnGreetingWithName()
{
Dictionnaire<string, object> input = nouveau dictionnaire
<chaîne, objet>()
{
{"Nom d'utilisateur", "Test"}
} ;
Sortie IDictionary<string, object> ;
sortie = WorkflowInvoker.Invoke(new SayHello(), input);
Assert.AreEqual("Bonjour, Test depuis Workflow 4", sortie["Greeting"]);
}
Activity dans 3.5 est la classe de base de toutes les activités. Pour implémenter des activités personnalisées, il vous suffit de remplacer la méthode Execute() d'Activity ; dans 4.0, toutes les activités sont dérivées de la classe abstraite WorkflowElement et sont personnalisées par défaut dans Visual Studio. . Les activités sont héritées de CodeActivity ou CodeActivity<T> De même, la méthode Execute() doit également être réécrite pour implémenter une logique d'exécution personnalisée.
classe publique MyActivity1 : CodeActivity
{
remplacement protégé void Execute (contexte CodeActivityContext)
{
//votre code d'implémentation
}
}
Bien sûr, vous pouvez toujours dériver des activités personnalisées à partir d’Activity, mais c’est très différent de la version 3.5.
classe publique SayHelloInCode : Activité
{
remplacement protégé WorkflowElement CreateBody()
{
renvoyer une nouvelle séquence()
{
Activités =
{
newWriteLine()
{
Texte = "Bonjour Workflow 4 dans le code"
}
}
} ;
}
}
La fonction de service de workflow nouvellement ajoutée dans 4.0 peut publier directement le workflow en tant que service WCF. Bien entendu, le workflow doit également être conçu avec la fonction de réponse WCF. 4.0 propose quatre activités liées à WCF : recevoir, recevoir une réponse, envoyer et envoyer une réponse. Grâce à ces activités, les opérations du service WCF peuvent être définies visuellement.
Le modèle de base du concepteur de flux de travail est implémenté dans la version 4.0 et les concepteurs personnalisés peuvent être facilement implémentés.