[WF4] Je n’aime pas les dictionnaires, mais vu que j’aime Workflow Foundation…

lundi 19 juillet 2010 17:59 JeremyJeanson

[WF4] Je n'aime pas les dictionnaires, mais vu que j'aime Workflow Foundation...

Je profite de cet article pour mettre noire sur blanc une grande réalité de WF : "Invoquer un workflow c'est sympa. Mais traiter son retour, ce n'est pas toujours drôle..."

A plusieurs reprises, j'ai donc cassé le moral à certain en affirmant la chose suivante : "Pour traiter les retours d'un workflow, il est impossible de passer directement par ses arguments de sortie comme si ils étaient des propriétés !"

Si par exemple on veut traiter un workflow héritant de Activity (et non pas de Activity<TResult>) avec un argument d'entrée Text et un argument de sortie Result de type String :

Il est impossible d'écrire ceci :

Workflow1 workflow = new Workflow1 { Text = "Mon text" };

String result = WorkflowInvoker.Invoke(workflow);

Il est aussi impossible d'écrire ceci :

Workflow1 workflow = new Workflow1 { Text = "Mon text" };

WorkflowInvoker.Invoke(workflow);

String result = workflow.Result;

La seule écriture possible reste ceci :

Workflow1 workflow = new Workflow1 { Text = "Mon text" };

IDictionary<String, Object> ret = WorkflowInvoker.Invoke(workflow);

result = ret["Result"].ToString();

On se retrouve donc toujours avec des méchantes conversions :(

Si votre activité n'a qu'un seul argument de sortie, je vous encourage donc à passer par un activité héritant de Activity<TResult> ou de l'un de ses dérivés.

Personnellement j'ai choisi une orientation POO en retournant toujours un seul argument Result et donc en utilisant Activity<TResult>. Cet argument est un objet exposant les données utiles sous forme de propriétés. Cela m'éviter certain problèmes de refactoring quand je change le nom d'une propriété ;)

Avec cette astuce :

• Pas de conversions sauvages.
• Moins de risques d'erreurs lors d'un quelconque refactoring.