Decidir quando implementar o padrão assíncrono baseado em evento

  • Artigo

O padrão assíncrono baseado em evento fornece um padrão para expor o comportamento assíncrono de uma classe. Com a introdução deste padrão, o .NET Framework define dois padrões para expor o comportamento assíncrono: o padrão assíncrono baseado na System.IAsyncResult interface e o padrão baseada em eventos. Este tópico descreve quando ele é adequado para implementar ambos os padrões.

Para obter mais informações sobre a programação assíncrona com o IAsyncResult interface, consulte Padrões de Design de programação assíncrona.

Princípios gerais

Em geral, você deve expor recursos assíncronos usando o Event-based Asynchronous padrão sempre que possível. No entanto, existem alguns requisitos que o padrão de eventos não pode atender. Nesses casos, talvez você precise implementar a IAsyncResult padrão com o padrão baseada em eventos.

Observação

É raro o IAsyncResult padrão para ser implementado sem o padrão de event-based também sendo implementado.

Diretrizes

A lista a seguir descreve as diretrizes para quando você deve implementar o padrão assíncrono baseado em evento:

  • Use o padrão de eventos como a API padrão para expor o comportamento assíncrono para sua classe.

  • Não exponha a IAsyncResult padrão, quando a sua classe, que é usada principalmente em um aplicativo de cliente, por exemplo Windows Forms.

  • Expor somente o IAsyncResult padrão, quando for necessário para atender suas necessidades. Por exemplo, a compatibilidade com uma API existente pode exigir expor o IAsyncResult padrão.

  • Não exponha a IAsyncResult padrão sem também expor o padrão baseada em eventos.

  • Se você deve expor o IAsyncResult padrão, tal como uma opção avançada. Por exemplo, se você gerar um objeto proxy, gerar o padrão de eventos por padrão, com uma opção para gerar o IAsyncResult padrão.

  • Sua implementação do padrão com base em eventos de compilação no seu IAsyncResult implementação do padrão.

  • Evite expor tanto o padrão baseada em eventos e o IAsyncResult padrão da mesma classe. Expor o padrão baseada em evento em "nível superior" classes e o IAsyncResult padrão de "nível inferior" classes. Por exemplo, compare o padrão de eventos na WebClient componente com o IAsyncResult padrão na HttpRequest classe.

    • Expor o padrão de eventos e o IAsyncResult padrão da mesma classe quando compatibilidade requer o proprietário. Por exemplo, se você já ter lançado uma API que usa o IAsyncResult padrão, você precisaria manter o IAsyncResult padrão para compatibilidade com versões anteriores.

    • Expor o padrão de eventos e o IAsyncResult padrão da mesma classe, se a complexidade de modelo de objeto resultante supera o benefício de separar as implementações. É melhor expor a ambos os padrões em uma única classe que para evitar expor o padrão de eventos.

    • Se você deve expor tanto o padrão baseada em eventos e IAsyncResult padrão de uma classe única, use EditorBrowsableAttribute definido como Advanced para marcar o IAsyncResult a implementação padrão como um recurso avançado. Isso indica a ambientes de design, como Visual Studio IntelliSense, não para exibir o IAsyncResult Propriedades e métodos. Essas propriedades e métodos ainda são completamente utilizáveis, mas o desenvolvedor trabalhando por meio de IntelliSense tem uma visão mais clara da API.

Critérios para expor o padrão do IAsyncResult, além do padrão de eventos

Enquanto o padrão assíncrono baseado em evento tem muitos benefícios em cenários mencionados anteriormente, ele tem algumas desvantagens que você deve estar ciente de desempenho é o requisito mais importante.

Há três cenários não aborda o padrão de eventos, bem como a IAsyncResult padrão:

Você pode lidar com esses cenários usando o padrão baseada em eventos, mas isso é mais complicado do que usando o IAsyncResult padrão.

Os desenvolvedores normalmente usam o IAsyncResult padrão para serviços que normalmente têm requisitos de desempenho muito alto. Por exemplo, a pesquisa para o cenário de conclusão é uma técnica de servidor de alto desempenho.

Além disso, o padrão de eventos é menos eficiente do que o IAsyncResult padrão porque ele cria mais objetos, especialmente EventArgs, e porque ele sincroniza entre threads.

A lista a seguir mostra algumas recomendações a seguir se você decidir usar o IAsyncResult padrão:

  • Expor somente o IAsyncResult padrão, quando você precisar especificamente o suporte para WaitHandle ou IAsyncResult objetos.

  • Expor somente o IAsyncResult padrão quando você tem uma API existente que usa o IAsyncResult padrão.

  • Se você tiver uma API existente com base na IAsyncResult padrão, considere também expondo o padrão baseada em evento em sua próxima versão.

  • Expor somente IAsyncResult padrão, se você tiver requisitos de alto desempenho que você verificou não podem ser atendida pelo padrão de eventos, mas podem ser atendida pela IAsyncResult padrão.

Consulte também

Tarefas

Demonstra Passo a passo: A implementação de um componente que suporta o padrão assíncrono baseado em evento

Conceitos

Implementando o padrão assíncrono baseado em evento

Práticas recomendadas para implementar o padrão assíncrono baseado em evento

Event-based Asynchronous Pattern Overview

Outros recursos

Padrões de Design de programação assíncrona

Programação multithread com o padrão assíncrono baseado em evento