Vendredi dernier Microsoft a publié le quatrième épisode des bonnes pratiques pour coder ses activités custom dans WF4 : endpoint.tv - Workflow and Custom Activities - Best Practices (Part 4).

Tout comme pour les précédents épisodes, j’ai pris le temps de regarder cette vidéo et d’en extraire quelques slides (4 au total)… un nouveau réveil vidéo/pop-corn avant d’aller au travail ;)

1 – Body versus Children

CustomActivities_BestPractices4Leon Welicki a voulu nous sensibiliser à une pratique de l’équipe WF4 sur le nommage des activités utilisées comme propriétés d’activités custom. Ces principes sont relativement simples :

- Si notre activité doit programmer l’exécution d’une seule activité, on nommera cette propriété Body. Tout comme Microsoft l’a fait avec les activités While, ForEach…etc..

- Si notre activité doit programmer l’exécution de plusieurs activités (comme une séquence custom) on choira un nom simple et personnalisé autre que Body. Le nom Activities étant quand même conseillé si vous exposez une collection d’activités.

A ceci s’ajoute une piqûre de rappel comme quoi, quand on code une activité on doit chercher à faire simple et laisser à l’utilisateur la possibilité de décider.

A partir du moment que votre activité peut contenir une activité, il est tout à fait probable que cette activité contienne une ou plusieurs autres activité… chacun sa responsabilité : ne cherchez donc pas à chaque fois à coder une séquence. Ajouter une propriété de type Activity nommé Body, et laissez l’utilisateur décider du reste.

On doit chercher en permanence à faire au plus simple.

2 – Les Variables

CustomActivities_BestPractices5Ce slide peut sembler inutile mais un petit rappel ne peut pas faire de mal.

- Le scope de variables (Collection<Varaible> Variables). Toujours dans l’idée de faire simple, on ne doit ajouter une collection de variables à une activité que ci celle-ci doivent être utilisées par les activités enfants. Tout comme pour les activités ForEach, While … etc…
C’est l’utilisateur final qui doit décider l’ajout d’un scope si il en a besoin (en mettant votre activité dans une séquence par exemple)

- ImplementationVaraibles… ne cherchez pas dans la MSDN, ce n’est pas une classe ;)
Le principe est simple : vos activité peuvent avoir des variables internes classique (Int32, String… etc…) qui en sont pas accessibles via l’extérieur de votre activité. Ces variable n’étant pas de type Variable<T>, elles ne font pas partie des metadata déclarées dans votre workflow. Leur état ne pourra donc pas persister avec votre worklow et donc ne pourront pas être ravivées. Pour évider ceci, il suffit donc de faire ce que l’on appel une “l’implémentation d’une variable”.

Exemple : pour une activité MySequence disposant d’un index, on déclare une variable interne et on enregistre sa metadata via la méthode AddImplementationVariable() de la NativeActivityMetadata. 
public class MySequence : NativeActivity
{
        private Variable<Int32> m_Index;

        public MyActivity()
        {
            this.m_Index = new Variable<Int32>();   
        }

        protected override void CacheMetadata(NativeActivityMetadata metadata)
        {
            // déclaration de l’“ImplementationVariable”
            metadata.AddImplementationVariable(this.m_Index);
        }
}

3 – CacheMetadata (oui encore!)

CustomActivities_BestPractices6 Une nouvelle petite dose sur la réécriture de la méthode CacheMetadata. Je crois que dans WF4 on n’a pas fini d’en reparler, tellement cette optimisation peut aller loin.

- La validation de l’activité passe par le metadata: j’ai déjà rédigé deux articles sur le sujet :
[WF4] Ajouter des contraintes à une activité (1/2) et [WF4] Ajouter des contraintes à une activité (2/2).
Leon Welicki a profité de ce slide pour rappeler la différence fondamentale entre ces deux approches :
La première permet de valider l’utilisation de l’activité hors du designer, la seconde ne permet la validation que via le designer de workflows.

- L’enregistrement des variables et arguments dynamiques. Il s’agit en fait des collections de variables et d’arguments qu’il faut parcourir pour enregistrer les éléments un à un. Rien de bien sorcier mais il est utile de le rappeler : Une collection ne peut pas s’enregistrer toute seule comme par magie!

- L’enregistrement de l’implémentation de varaibles internes dont j’ai donné un exemple un peu plus haut.

- Le fait de ne pas utiliser la réflexion : Il s’agit souvent du seul avantage que l’on retiens. Dernièrement, j’ai posté un article exposant l’enregistrement de chaque type de metadata :
[WF4] Optimiser l’implémentation de vos activités composites 

4 – Keep It Simple,… Stupid (KISS)

CustomActivities_BestPractices7Ce dernier slide résume en fait la vidéo : “Faisons simple et ne compliquons pas la vie, elle l’est déjà assez!”

- Une activité = Une responsabilité pourrait être un bon résumé. Il ne faut en aucun cas chercher à coder une activité chargée de répondre à 10 ou 30 scénarios différents, c’est une perte de temps et de performances…

- Avec un nouveau rappel sur un concept fort intéressant : la composition. Sujet sur lequel j’ai présenté plusieurs variantes pas plus tard qu’hier : [WF4] Réaliser une activité i++ en respectant les bonnes pratiques. L’objectif est simple : favorisé l’utilisation de ce qui existe plutôt que de réinventer la roue.

Dans ce cadre, il nous est aussi conseillé de favoriser la composition d’une activité à l’héritage.

J’attends avec impatience la suite…