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

  • Article

Le modèle asynchrone basé sur des événements fournit un modèle pour exposer le comportement asynchrone d’une classe. Avec l’introduction de ce modèle, .NET 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. Cet article décrit les cas où il convient d’implémenter les deux modèles.

Pour plus d’informations sur la programmation asynchrone avec l’interface IAsyncResult, consultez Modèle de programmation asynchrone.

Principes généraux

En règle générale, vous devez, dans la mesure du possible, exposer les fonctionnalités asynchrones à l’aide du modèle asynchrone basé sur les événements. Ce modèle ne répond toutefois pas à certaines exigences spécifiques. Dans ces cas particuliers, vous devez implémenter le modèle IAsyncResult en plus du modèle basé sur les événements.

Notes

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

Consignes

La liste suivante décrit les instructions à suivre si 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 si votre classe est principalement utilisée dans une application cliente, par exemple Windows Forms.

  • Exposez uniquement le modèle IAsyncResult s’il est nécessaire pour répondre à vos exigences. Par exemple, la compatibilité avec une API existante peut nécessiter l’exposition du modèle IAsyncResult.

  • 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.

  • Effectuez votre implémentation du modèle basé sur les événements à partir de votre implémentation du modèle IAsyncResult.

  • Évitez d’exposer à la fois 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 des classes de « niveau supérieur », et le modèle IAsyncResult sur des classes de « niveau inférieur ». Par exemple, comparez le modèle basé sur les événements sur le composant WebClient avec le 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 quand la compatibilité l’exige. Par exemple, si vous avez déjà publié une API qui utilise le modèle IAsyncResult, vous devez conserver le modèle IAsyncResult pour la 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 objet résultant empêche de tirer avantage de la séparation des implémentations. Il vaut mieux exposer les deux modèles sur une même classe que de ne pas exposer le modèle basé sur les événements.

    • Si vous devez exposer à la fois le modèle basé sur les événements et le modèle IAsyncResult sur une même classe, utilisez l’attribut EditorBrowsableAttribute défini sur Advanced pour marquer l’implémentation du modèle IAsyncResult comme une fonctionnalité avancée. Cela indique aux environnements de conception, comme Visual Studio IntelliSense, de ne pas afficher les méthodes et les propriétés IAsyncResult. Ces méthodes et propriétés sont toujours utilisables, mais le développeur qui travaille avec IntelliSense a une vue plus claire de l’API.

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

Le modèle asynchrone basé sur les événements présente de nombreux avantages dans les cas mentionnés précédemment, mais également quelques inconvénients que vous devez prendre en compte si les performances sont essentielles pour vous.

Il existe trois scénarios dans lesquels le modèle basé sur les événements et le modèle IAsyncResult ne fonctionnent pas :

Vous pouvez gérer ces scénarios à l’aide du modèle basé sur les événements, mais cela s’avère plus fastidieux que d’utiliser du modèle IAsyncResult.

Les développeurs utilisent souvent le modèle IAsyncResult pour les services qui exigent généralement de très hautes performances. Par exemple, l’interrogation pour connaître l’état d’avancement est une technique serveur hautes performances.

Par ailleurs, le modèle basé sur les événements est moins efficace que le modèle IAsyncResult parce qu’il crée davantage d’objets, en particulier d’arguments EventArgs, et qu’il se synchronise à travers les différents threads.

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

  • Exposez uniquement le modèle IAsyncResult si vous avez besoin de prendre spécifiquement en charge des objets WaitHandle ou IAsyncResult.

  • Exposez uniquement le modèle IAsyncResult si vous avez une API existante qui utilise le modèle IAsyncResult.

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

  • Exposez uniquement le modèle IAsyncResult si vous exigez de hautes performances qui ne peuvent pas être atteintes avec le modèle basé sur les événements, mais qui peuvent l’être avec le modèle IAsyncResult.

Voir aussi