[WF4] les conditions de workflow foundation 4?!!! (ou decouplage de la logique)

vendredi 25 juin 2010 11:17 JeremyJeanson

[WF4] les conditions de workflow foundation 4?!!! (ou decouplage de la logique)

Le titre de ce poste pourra sembler étrange (j'entends déjà certain dire :"Comme tout ce que tu postes ;)"... ce n'est pas faut) mais il résulte d'un constat. Il y a encore des développeurs qui sont perdus quand ils passent de Workflow Foundation 3 à 4 et je les comprends. Parmi eux se trouvent des personnes qui sont à la recherche "Des condition de WF4". Par-là, il faut comprendre qu'ils souhaitent coder leurs conditions à l'ancienne comme ceci :

private void MyCondition(object sender, ConditionalEventArgs e)
{
    e.Result = true | false;
}

Effectivement en WF3 on avait là la méthode la plus "triviale" pour retrouver ses petits. En WF4, cela n'existe plus. On doit passer par une expression Vb...

Donc en théorie on devrait utiliser un code de ce style :

Mais dans une situation où l'on souhaite coder "à la mode WF3", on ne veut pas entendre parler d'expression. On veut séparer la logique du design de workflow, un point c'est tout.

En toute logique on portera son attention vers une méthode externe. Pour cela, nul besoin d'utiliser des fonctionnalités particulières. Un code tel que celui-ci suffira pour faire un simple test et retourner un Boolean au workflow :

public static class MyConditions
{
    public static Boolean MyCondition1()
    {
        return true | false;
    }
}

Et l'utilisation reste tout aussi simple :

Attention si votre classe statique n'est pas dans le même namspace que votre workflow, il faudra penser à l'utiliser dans l'appel de la méthode ou alors plus simplement importer dans la section "Imports" en bas de designer de workflows.

Pourquoi peut-on se permettre ce genre de choses?

La réponse est très simple : Malgré votre allergie possible aux expressions Vb, vous venez d'en écrire une. Votre appel à votre méthode s'écrit de la même manière en Vb qu'en C#. Il y a peut-être là pour vous un moyen de contourner la "contrainte Vb".

Et si on envisageait d'utiliser des arguments?

Idem : pas de stress. On a une méthode qui ne dépend pas de workflow et qui initialisera la VisualBacisValue induite par la présence de votre expression Vb :

Voici donc le code:

public static class MyConditions
{
    public static Boolean MyCondition2(Boolean argument1, Boolean argument2)
    {
        return argument1 | argument2;
    }
}

Et son utilisation (à condition d'avoir deux variables de type Boolean dans votre workflow (Variable<Boolean>)

Et si on restait dans une idée de découplage de la logique et de la définition mais que l'on utilise une approche plus orientée WF4?

La réponse logique à cette nouvelle problématique est évidente : on fait un CodeActivity<Boolean>

public sealed class MyConditionActivity : CodeActivity<Boolean>
{
    public InArgument<Boolean> Argument1 { get; set; }
    public InArgument<Boolean> Argument2 { get; set; }

    protected override bool Execute(CodeActivityContext context)
    {
        return this.Argument1.Get(context) | this.Argument2.Get(context);
    }
}

Il va s'en dire que pour utiliser cette activité on va commencer par l'introduire dans la séquence du workflow et affecter les variables variable1 et variable2 via les arguments d'entrée Argument1 et Argument2. Il faudra aussi ajouter une variable test de type Boolean et l'affecter à la propriété Result de notre CodeActivity. On utilise ensuite la variable test dans le If et le tour est joué.

Là on a un logique séparée de la définition du workflow et on ne code que du C# (on peut aussi le faire en Vb).

J'insiste peut être un peu trop, mais si vous n'avez pas besoin de séparer votre "logique" du workflow... écrivez du Vb. Ceci est peut-être un peu douloureux au début... mais après cela passe tout seul ;)

Et en bonus, pour ceux qui voudrait bien comprendre un peu plus la correspondance que quelques éléments de logique entre Vb/C#: