Partager via


Choix du moment auquel implémenter le modèle asynchrone basé sur les événements

Le modèle asynchrone basé sur les événements fournit un modèle visant à exposer le comportement asynchrone d'une classe. Avec l'introduction de ce modèle, le .NET Framework définit deux modèles pour exposer le comportement asynchrone : le modèle asynchrone basé sur l'interface System.IAsyncResult et le modèle basé sur les événements. Cette rubrique décrit les circonstances dans lesquelles implémenter chacun des deux modèles.

Pour plus d'informations sur la programmation asynchrone avec l'interface IAsyncResult, consultez Modèles de conception pour la programmation asynchrone.

Principes généraux

En général, vous devez exposer des fonctionnalités asynchrones à l'aide du modèle asynchrone basé sur les événements chaque fois que c'est possible. Toutefois, le modèle basé sur les événements ne peut répondre à certaines exigences. Dans de tels cas, vous devez parfois implémenter le modèle IAsyncResult en plus du modèle basé sur les événements.

RemarqueRemarque

Il est rare d'implémenter le modèle IAsyncResult sans implémenter également le modèle basé sur les événements.

Indications

La liste suivante décrit les indications à respecter lorsque vous devez implémenter le modèle asynchrone basé sur les événements :

  • Utilisez le modèle basé sur les événements comme API par défaut pour exposer le comportement asynchrone de votre classe.

  • N'exposez pas le modèle IAsyncResult lorsque votre classe est principalement utilisée dans une application cliente, par exemple Windows Forms.

  • Exposez uniquement le modèle IAsyncResult lorsque vos besoins l'exigent. Par exemple,il se peut que vous deviez exposer le modèle IAsyncResult à des fins de compatibilité avec une API existante.

  • N'exposez pas le modèle IAsyncResult sans exposer également le modèle basé sur les événements.

  • Si vous devez exposer le modèle IAsyncResult, faites-le en tant qu'option avancée. Par exemple, si vous générez un objet proxy, générez le modèle basé sur les événements par défaut, avec une option pour générer le modèle IAsyncResult.

  • Créez votre implémentation du modèle basé sur les événements sur votre implémentation du modèle IAsyncResult.

  • Évitez d'exposer le modèle basé sur les événements et le modèle IAsyncResult sur la même classe. Exposez le modèle basé sur les événements sur les classes de « niveau supérieur » et le modèle IAsyncResult sur les classes de « niveau inférieur ». Comparez, par exemple, le modèle basé sur les événements sur le composant WebClient au modèle IAsyncResult sur la classe HttpRequest.

    • Exposez le modèle basé sur les événements et le modèle IAsyncResult sur la même classe lorsque la compatibilité l'exige. Si, par exemple, vous avez déjà publié une API qui utilise le modèle IAsyncResult, vous devez conserver le modèle IAsyncResult à des fins de compatibilité descendante.

    • Exposez le modèle basé sur les événements et le modèle IAsyncResult sur la même classe si la complexité du modèle d'objet résultant neutralise l'avantage conféré par la séparation des implémentations. Il est préférable d'exposer les deux modèles sur une même classe que de ne pas pouvoir exposer le modèle basé sur les événements.

    • Si vous devez exposer le modèle basé sur les événements et le modèle IAsyncResult sur une même classe, utilisez EditorBrowsableAttribute avec la valeur Advanced pour marquer l'implémentation du modèle IAsyncResult comme une fonctionnalité avancée. La définition de cet attribut indique aux environnements de design, tels que Visual Studio IntelliSense, de ne pas afficher les propriétés et les méthodes IAsyncResult. Ces propriétés et méthodes sont toujours utilisables mais le développeur qui se sert d'IntelliSense possède une vue plus claire de l'API.

Critères justifiant l'exposition du modèle IAsyncResult en plus du modèle basé sur les événements

Si le modèle asynchrone basé sur les événements comporte de nombreux avantages dans les scénarios précités, il présente toutefois quelques inconvénients dont vous devez être conscient si les performances sont essentielles pour vous.

Le modèle basé sur les événements s'avère moins adapté que le modèle IAsyncResult dans trois cas de figure :

Vous pouvez, certes, utiliser le modèle basé sur les événements dans ces scénarios mais c'est plus fastidieux qu'avoir recours au modèle IAsyncResult.

Les développeurs utilisent souvent le modèle IAsyncResult pour les services qui exigent des performances élevées. Par exemple, le scénario d'interrogation sur l'achèvement est une technique serveur hautes performances.

En outre, le modèle basé sur les événements est moins efficace que le modèle IAsyncResult parce qu'il crée davantage d'objets, surtout des objets EventArgs et qu'il effectue une synchronisation entre les threads.

La liste suivante affiche quelques recommandations à suivre si vous décidez d'utiliser le modèle IAsyncResult :

  • Exposez uniquement le modèle IAsyncResult lorsque vous avez spécifiquement besoin d'une prise en charge des objets WaitHandle ou IAsyncResult.

  • Exposez uniquement le modèle IAsyncResult lorsqu'une API existante utilise le modèle IAsyncResult.

  • Si vous avez une API existante basée sur le modèle IAsyncResult, envisagez d'exposer également le modèle basé sur les événements dans votre prochaine version.

  • Exposez uniquement le modèle IAsyncResult si vous avez des exigences élevées en termes de performances qui s'avèrent, après vérification, impossibles à satisfaire avec le modèle basé sur les événements mais bien avec le modèle IAsyncResult.

Voir aussi

Tâches

Procédure pas à pas : implémentation d'un composant qui prend en charge le modèle asynchrone basé sur des événements

Concepts

Implémentation du modèle asynchrone basé sur des événements

Meilleures pratiques pour implémenter le modèle asynchrone basé sur des événements

Vue d'ensemble du modèle asynchrone basé sur des événements

Autres ressources

Modèles de conception pour la programmation asynchrone

Programmation multithread avec le modèle asynchrone basé sur les événements