Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
A definição do escopo e visibilidade da atividade, tal como o escopo e a visibilidade de um objeto, refere-se à capacidade de outros objetos ou atividades acessarem os elementos da atividade. A definição da atividade é realizada pelas seguintes implementações:
Determinar os membros (Argument, Variable, e ActivityDelegate objetos, e atividades filhas) que uma atividade expõe aos seus usuários.
Implementação da lógica de execução da atividade
A implementação pode incluir membros que não são visíveis para os consumidores da atividade, mas sim detalhes internos da própria implementação. Semelhante à definição de tipo, o modelo de atividade permite que um autor qualifique a visibilidade de um membro da atividade em relação à definição da atividade que está sendo definida. Esta visibilidade governa aspetos da utilização dos membros, como a delimitação de dados.
Âmbito de aplicação
Além do escopo dos dados, a visibilidade do modelo de atividade pode restringir o acesso a outros aspetos da atividade, como validação, depuração, rastreamento ou rastreamento detalhado. As propriedades de execução usam visibilidade e escopo para restringir as características de execução a um escopo específico de definição. As raízes secundárias usam a visibilidade e o escopo para restringir o estado capturado por a CompensableActivity ao escopo de definição em que as atividades compensáveis são usadas.
Definição e utilização
Um fluxo de trabalho é escrito criando novas atividades herdando de classes de atividade base e usando atividades da Biblioteca de Atividades doBuilt-In. Para usar uma atividade, o autor da atividade deve configurar a visibilidade de cada componente de sua definição.
Membros da Atividade
O modelo de atividade define os argumentos, as variáveis, os delegados e as atividades filhas que a atividade disponibiliza aos consumidores. Cada um destes membros pode ser declarado como public ou private. Os membros públicos são configurados pelo consumidor da atividade, enquanto private os membros usam uma implementação fixada pelo autor da atividade. As regras de visibilidade para o escopo de dados são as seguintes:
Os membros públicos e os membros de atividades infantis públicas podem referenciar variáveis públicas.
Os membros privados e os membros públicos de atividades infantis públicas podem referenciar argumentos e variáveis privadas.
Um membro que pode ser definido pelo consumidor de uma atividade nunca deve ser tornado privado.
Criação de modelos
As atividades personalizadas são definidas usando NativeActivity, Activity, CodeActivity, ou AsyncCodeActivity. As atividades que derivam dessas classes podem expor diferentes tipos de membros com diferentes visibilidades.
NativeActivity
As atividades que derivam de NativeActivity têm um comportamento que é escrito em código imperativo e podem, opcionalmente, ser definidas usando atividades existentes. Derivar atividades de NativeActivity concede acesso a todas as funcionalidades expostas pelo runtime. Qualquer membro de tal atividade pode ser definido usando visibilidade pública ou privada, exceto argumentos, que só podem ser declarados como public.
Membros de classes derivadas de NativeActivity são declarados para o tempo de execução usando a struct NativeActivityMetadata passada para o método CacheMetadata.
Atividade
As atividades criadas usando Activity têm um comportamento que é projetado estritamente através da composição de outras atividades. A Activity classe tem uma atividade filha de implementação, obtida em tempo de execução usando Implementation. Uma atividade derivada de Activity pode definir argumentos públicos, variáveis públicas, ActivityDelegates importados e Atividades importadas.
Atividade importadaDelegados e Atividades são declarados como filhos públicos da atividade, mas não podem ser agendados diretamente pela atividade. Essas informações são usadas durante a validação para evitar a execução de validações voltadas para os pais em locais onde a atividade nunca será executada. Além disso, crianças importadas, assim como crianças públicas, podem ser referenciadas e agendadas pela implementação da atividade. Isso significa que uma atividade que importa uma atividade chamada Atividade1 pode conter um Sequence em sua implementação que agenda a Atividade1.
CodeActivity/ AsyncCodeActivity
Essa classe base é usada para o comportamento de criação em código imperativo. As atividades que derivam dessa classe só têm acesso aos argumentos que expõem. Isso significa que os únicos membros que essas atividades podem expor são argumentos públicos. Nenhum outro membro ou outra visibilidade se aplica a estas atividades.
Resumo das visibilidades
A tabela a seguir resume as informações anteriores nesta seção.
| Tipo de Membro | NativeActivity | Atividade | CodeActivity/ AsyncCodeActivity |
|---|---|---|---|
| Argumentos | Público/Privado | Público | não aplicável |
| Variáveis | Público/Privado | Público | não aplicável |
| Atividades Infantis | Público/Privado | Público, um filho privado fixo definido em Implementação. | não aplicável |
| Delegados de Atividade | Público/Privado | Público | não aplicável |
Em geral, um membro que não possa ser definido pelo consumidor de uma atividade não deve ser tornado público.
Propriedades de execução
Em alguns cenários, é útil delimitar o âmbito de uma determinada propriedade de execução para os elementos públicos de uma atividade. A ExecutionProperties coleção fornece esse recurso com o Add método. Esse método tem um parâmetro booleano que indica se uma determinada propriedade é aplicada a todos os filhos ou apenas aos que são públicos. Se este parâmetro for definido como true, a propriedade será visível apenas para membros públicos e para os membros públicos dos seus descendentes públicos.
Raízes Secundárias
Uma raiz secundária é o mecanismo interno do ambiente de execução para gerir o estado de atividades de compensação. Quando um CompensableActivity termina de ser executado, o seu estado não é imediatamente limpo. Em vez disso, o estado é mantido pelo runtime numa raiz secundária até que o processo de compensação seja concluído. Os ambientes de localização capturados pela raiz secundária correspondem ao âmbito de definição em que se utiliza a atividade Compensable.