Definizione dell'attività Definizione dell'ambito e visibilità

La definizione dell'ambito e della visibilità di un'attività, proprio come l'ambito e la visibilità di un oggetto, determina la possibilità per altri oggetti o attività di accedere ai membri dell'attività. La definizione di attività viene eseguita dalle implementazioni seguenti:

1. Determinare i membri (Argument, Variable, e gli oggetti ActivityDelegate e le attività figlio) che un'attività espone ai suoi utenti.

2. Implementazione della logica di esecuzione dell'attività

L'implementazione può includere membri che non sono esposti agli utenti dell'attività, ma sono più dettagli dell'implementazione. Analogamente alla definizione del tipo, il modello di attività consente a un autore di qualificare la visibilità di un membro dell'attività relativa alla definizione dell'attività definita. Questa visibilità regola gli aspetti dell'utilizzo dei membri, ad esempio la definizione dell'ambito dei dati.

Ambito

Oltre alla definizione dell'ambito dei dati, la visibilità del modello di attività può limitare l'accesso ad altri aspetti dell'attività, ad esempio la convalida, il debug, il rilevamento o la traccia. Le proprietà di esecuzione usano visibilità e ambito per vincolare le caratteristiche di esecuzione a un determinato ambito di definizione. Le radici secondarie usano visibilità e ambito per vincolare lo stato acquisito da un CompensableActivity all'ambito di definizione in cui vengono usate le attività compensabili.

Definizione e utilizzo

Un flusso di lavoro viene scritto creando nuove attività ereditando dalle classi di attività di base e usando le attività della libreria attivitàBuilt-In. Per usare un'attività, l'autore dell'attività deve configurare la visibilità di ogni componente della relativa definizione.

Membri dell'attività

Il modello di attività definisce gli argomenti, le variabili, i delegati e le attività figlio che l'attività rende disponibili ai consumatori. Ognuno di questi membri può essere dichiarato come public o private. I membri pubblici vengono configurati dall'utilizzatore dell'attività, mentre i membri private usano un'implementazione fissa dell'autore dell'attività. Di seguito sono riportate le regole di visibilità per la definizione dell'ambito dei dati:

1. I membri pubblici e i membri delle attività figlio pubbliche possono fare riferimento a variabili pubbliche.

2. I membri privati e i membri pubblici delle attività pubbliche dei figli possono fare riferimento ad argomenti e variabili private.

Un membro che può essere impostato dall'utente di un'attività non deve mai essere reso privato.

Creazione di modelli

Le attività personalizzate vengono definite tramite NativeActivity, Activity, CodeActivityo AsyncCodeActivity. Le attività che derivano da queste classi possono esporre tipi di membri diversi con visibilità diverse.

NativeActivity

Le attività che derivano da NativeActivity hanno un comportamento scritto nel codice imperativo e possono essere definite facoltativamente usando le attività esistenti. Derivare attività da NativeActivity concede l'accesso a tutte le funzionalità esposte dal runtime. Qualsiasi membro di tale attività può essere definito usando visibilità pubblica o privata, ad eccezione degli argomenti, che possono essere dichiarati solo come public.

I membri delle classi derivate da NativeActivity vengono dichiarati al runtime usando lo NativeActivityMetadata struct passato al CacheMetadata metodo .

Attività

Le attività create usando Activity hanno un comportamento progettato rigorosamente tramite la composizione di altre attività. La Activity classe ha un'attività figlio di implementazione, ottenuta dal runtime usando Implementation. Un'attività che deriva da Activity può definire argomenti pubblici, variabili pubbliche, ActivityDelegates importati e attività importate.

Attività importate, Delegati di attività e Attività sono dichiarati come figli pubblici dell'attività, ma non possono essere programmate direttamente dall'attività stessa. Queste informazioni vengono utilizzate durante la convalida per evitare l'esecuzione di convalide rivolte al genitore in posizioni in cui l'attività non verrà mai eseguita. Inoltre, i figli importati, come i figli pubblici, possono essere richiamati e pianificati dall'implementazione dell'attività. Ciò significa che un'attività che importa un'attività denominata Activity1 può contenere un oggetto Sequence nell'implementazione che pianifica Activity1.

CodeActivity / AsyncCodeActivity

Questa classe di base viene usata per la creazione di comportamenti nel codice imperativo. Le attività che derivano da questa classe hanno accesso solo agli argomenti esposti. Ciò significa che gli unici membri che queste attività possono esporre sono argomenti pubblici. Nessun altro membro né altre visibilità si applicano a queste attività.

Riepilogo delle visibilità

La tabella seguente riepiloga le informazioni riportate in precedenza in questa sezione.

Tipo di membro	NativeActivity	Attività	CodeActivity/ AsyncCodeActivity
Argomenti	Pubblico/Privato	Pubblico	non applicabile
Variabili	Pubblico/Privato	Pubblico	non applicabile
Attività per bambini	Pubblico/Privato	Pubblico, un figlio privato fisso definito in Implementazione.	non applicabile
DelegatiAttività	Pubblico/Privato	Pubblico	non applicabile

In generale, un membro che non può essere impostato dall'utente di un'attività non dovrebbe essere reso pubblico.

Proprietà di esecuzione

In alcuni scenari, è utile limitare una particolare proprietà di esecuzione agli elementi figlio pubblici di un'attività. La raccolta ExecutionProperties fornisce questa funzionalità con il metodo Add. Questo metodo ha un parametro booleano che indica se una determinata proprietà è applicabile a tutti i figli o solo a quelli pubblici. Se questo parametro è impostato su true, la proprietà sarà visibile solo ai membri pubblici e ai membri pubblici dei figli pubblici di tali membri.

Radici secondarie

Una radice secondaria è il meccanismo interno del runtime per la gestione dello stato per le attività di compensazione. Quando un CompensableActivity ha terminato l'esecuzione, il suo stato non viene pulito immediatamente. Lo stato viene invece mantenuto dal runtime in una radice secondaria fino al completamento dell'episodio di compensazione. Gli ambienti di posizione acquisiti con la radice secondaria corrispondono all'ambito di definizione in cui viene usata l'attività compensabile.