WF4 Best Practice

Base Classes

1. Limitare l’uso del Designer per le Activity/WF di cui si desidera ottenere una rappresentazione visiva (grafica);
2. Utilizzare la derivazione direttamente dalla classe Activity quando si desiderano implementare concetti non direttamente supportati a livello di Designer. Ad esempio: ActivityDelegate, child activities e validation;
3. Quando si ha la necessità di scrivere le proprie Custom Activity by code (imperative code), derivare la nuova Activity da CodeActivity se si vuole: 
   1. gestire l’esecuzione in un unico punto (metodo Execute) 
   2. non si necessità di schedulare ulteriori Activity 
   3. non si richiedono funzionalità avanzate del WF Runtime 
   4. non si richiede l’esecuzione asincrona 
4. Quando si ha la necessità di scrivere le proprie Custom Activity by code (imperative code), derivare la nuova Activity da AsyncCodeActivity se si ha la necessità di eseguire la stessa in modo asincrono in aggiunta alle caratteristiche del punto 3; 
5. Quando si ha la necessità di sfruttare tutte le potenzialità del WF Runtime, superando i limiti del punto 3, derivare la nuova Activity da NativeActivity; 
6. Non derivare una Custom Activity da NativeActivity se non si ha la necessità di utilizzare le feauture avanzate del WF Runtime; 
7. Favorire sempre il Riuso delle Activity già esistenti, creando nuove Activity frutto dell’orchestrazione di quelle esistenti (Composition); 
8. Creare nuove Activitiy derivate da Code/NativeActivity solo se non è possibile implementarle facilmente attraverso Composition; 
9. Utilizzare la base class Activity<TResult>/CodeActivity<TResult> (invece che Activity/CodeActivity) se l’Activity deve ritornare un valore.

Execution

1. Non effettuare Chiamate Bloccanti all’interno di un Activity; 
2. Effettuare le operazione di I/O tramite Activity che sfruttano l’ Asynchronous Activity Pattern e non creando in proprio un nuovo thread di esecuzione (per esempio tramite Thread.Start); 
3. Accertarsi che gli Argument e le Variable siano sempre di un tipo serializzabile. L’unica eccezione ammessa è per i tipi utilizzati nella NoPersistZone;
4. Se si implementano logiche di annullamento: 
   1. a. Accertarsi che l’istanza del Workflow venga lasciata in uno Stato Consistente; 
   2. b. Non annullare l’Activity se le attività relative alla sua esecuzione non sono cancellabili 
   3. Se l’operazione è annullabile, supportare tale opzione; 

Performance

1. Considerare la possibilità di effettuare l’ovverride del metodo CacheMetadata per evitare la Reflection (parametri, var, sub activity); 
2. Considerare la possibilità di cache dei callback delegate se utilizzati più volte; 
3. Considerare di ottimizzare l’accesso alle variabili di contesto, invocando una sola volta il Get; 
4. Dichiarare le variabili con lo scoop più fine possibile (tightly scoped). 

Activity Design: Properties vs. Arguments vs. Activities

1. Utilizzare gli Argument (In, Out, InOut) per le espressioni che sono valutate una sola volta prima dell’esecuzione dell’Activity. Per esempio: If.Condition; WriteLine.Text
2. Utilizzare Activity<TResult> per le espressioni che possono essere ri-valutate più di una volta;
3. Utilizzare le CLR-Proprierty per tutti gli elementi che non cambiano durante l’intero ciclo di vita dell’istanza del workflow;

Activity Design: Body vs Children

1. Usare un Body Activity (Activity che contengono altre Activity) quando è necessario schedulare una singola Activity figlia, come, per esempio: While, CancellationScope, TransactionScope;
2. Aggiungere una proprietà Children-like se l’Activity coordina l’esecuzione di Activity figlie. Per esempio: Sequence e Parallel
3. Se può avere solo un’activity figlia, deve avere solo un’activity figlia.

Activity Design: Variables

1. Aggiungere una o più Variable collection ad un’Activity che ha bisogno di condividere i dati (sharing data) tra i propri figli. Per esempio: Sequence e Pick; 
2. Non aggiungere una Variable colletion se non è richiesto lo sharign data tra i figli. Per esempio: ForEach; 
3. Uitlizzare ImplementationVariables (variabili locali) per salvare lo stato iniziale di una Activity. 

Activity Design: CacheMetadata

1. Effettuare l’ovveride del metodo CacheMetadata di un’Activity per:
   1. Aggiungere validazione;
   2. Registrare argument/variable dinamiche;
   3. Registrare variabili locali;
   4. Eliminare le operazioni di Reflection;

Activity Design – Parallel work

1. Schedulare più AsyncCodeActivity se è necessario ottenere un’esecuzione parallela (thread parallelism WF Parallel)
   1. Non creare i propri Thread all’interno dell’Activity (es. Thread.Start);
   2. Considerare l’utilizzo di un AsyncActivity che sfrutta il TaskParallel;

Activity Design:

1. Evitare la programmazione stile “Swiss Army Knife”, ovvero l’accorpamento di più funzionalità eterogenee tra loro:
   1. Realizzare Activiy semplici;
   2. KISS (Keep It Simple Stupid)
2. Utilizzare la Composizione piuttosto che la Derivazione;
3. Rendere Seal le proprie Activity;

XAML  Serialization

1. Utilizzare Create / Set / Use Pattern per i tipi;
2. Utilizzare [DefaultValue(null)] per evitare la serializzazione di proprietà non necessarie; 
3. Considerare l’uso di [DependsOn] per controllare l’ordine di serializzazione delle proprietà; 
4. Serializzazione XAML; 
5. Utilizzare [ContentProperty] nelle Activity composite; 
   1. Se dispone della proprietà BODY, considerare di usarla come ContentProperty; 
   2. Se dispone di una collection di Activity (figlie), considerare di usarla come ContentProperty 

Naming

1. Non aggiungere il suffisso Activity;
2. Non aggiungere il suffisso Argument o Arg per gli Argomenti;
3. Non aggiungere il suffisso Variable o Var per le Variabili;
4. Valutare l’utilizzo del suffisso “Scope” per le Activity disegnate per decorare altre activity e aggiungere un significato semantico; 

Execution Properties

1. Utilizzare Exection Properties per settare proprietà relative al context;
2. Utilizzare Exection Properties per condividere dati di contesto tra Activity padre e Activity figlia, ovvero schedulata dalla prima;
3. Utilizzare nomi per le Exection Properties che siano rappresentativi del contenuto;

Validation

1. Utilizzare l’attributo RequiredArguments;
2. Considerare l’utilizzo di OverloadGroups per una serie di argomenti che devono essere settati insieme;
3. Non assumere che un parametro richiesto non possa essere Null.;

Validation – Rules

1. Ritornare un Error quando non è possibile utilizzare eseguire l’Activity in relazione ai settaggi o all’ambiente;
2. Ritornare un Warning quando è presente un’ambiguità nell’utilizzo dei settaggi o all’ambiente l’esecuzione dell’Activity;
3. Non ritornare un Error o un Warning quando è possibile eseguire l’Activity in relazione ai settaggi o all’ambiente, anche se in presenza, ad esempio, di una sequenza di dati vuota;