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…

WF4_If_0

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

WF4_If_1

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 :

WF4_If_3

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>)

WF4_If_4

 

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é.

WF4_If_5

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 ;)

WF4_If_6

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

Condition C# Vb
Et & And
Et de court circuit && AndAlso
Ou | Or
Ou de court circuit || OrElse
Ou exclusif ^ xOr
Egual à == =
Différent de != <>
Inverser un Boolean ! Not