Dans certain cas tordus, on peut avoir envie d’une zone dans laquelle la persistance ne peut s’appliquer. Pour arriver à coder une activité qui permette ce comportement, la manouvre n’est pas très compliquée mais il faut connaitre la classe NoPersistHandle et la notion d’ImplementationVariable.

Petit rappel : l’ImplementationVariable est une variable interne à une activité de type Variable<T>. Ce type aillant besoin du contexte WF pour être utilisé, il doit donc être déclarée dans la metadata.

Voici le code typique d’un scope interdisant le persistance :

[ContentProperty("Body")]
public sealed class NoPersistScope : NativeActivity
{
    private Variable<NoPersistHandle> m_NoPersistHandle;

    [DefaultValue(null)]
    public Activity Body { get; set; }

    /// <summary>
    /// Constructeur
    /// </summary>
    public NoPersistScope()
    {
        this.m_NoPersistHandle = new Variable<NoPersistHandle> { Name = "NoPersistHandle" };
    }

    /// <summary>
    /// 
    /// </summary>
    /// <param name="metadata"></param>
    protected override void CacheMetadata(NativeActivityMetadata metadata)
    {
        metadata.AddChild(this.Body);
        metadata.AddImplementationVariable(this.m_NoPersistHandle);
    }

    protected override void Execute(NativeActivityContext context)
    {
        if (this.Body != null)
        {
            NoPersistHandle handle = this.m_NoPersistHandle.Get(context);
            handle.Enter(context);
                
            context.ScheduleActivity(this.Body);
        }
    }
}

L’utilisation de la Méthode Exit du NoPersistHandle n’est pas obligatoire, mais il peut être envisagé si on utilise un CallBack sur la méthode Schedule du contexte.

PS : Attention quand même à ne pas mettre d’activité Persist dans ce scope ;) (si vous voulez interdire ce comportement, il faudra regarder du côté des contraintes)