Partager via

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

Le modèle asynchrone basé sur les événements fournit un modèle permettant d’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 quand il est approprié d’implémenter les deux modèles.

Pour plus d’informations sur la programmation asynchrone avec l’interfaceIAsyncResult, consultez Le modèle de programmation asynchrone (APM).

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 dans la mesure du possible. Toutefois, il existe certaines exigences que le modèle basé sur les événements ne peut pas respecter. Dans ces cas, vous devrez peut-être implémenter le IAsyncResult modèle en plus du modèle basé sur les événements.

Remarque

Il est rare que le IAsyncResult modèle soit implémenté sans que le modèle basé sur les événements soit également implémenté.

Lignes directrices

La liste suivante décrit les instructions pour lesquelles 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 IAsyncResult modèle lorsque votre classe est principalement utilisée dans une application cliente, par exemple Windows Forms.

  • Exposez uniquement le IAsyncResult modèle lorsqu’il est nécessaire de répondre à vos besoins. Par exemple, la compatibilité avec une API existante peut vous obliger à exposer le IAsyncResult modèle.

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

  • Si vous devez exposer le IAsyncResult modèle, 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 permettant de générer le IAsyncResult modèle.

  • Générez votre implémentation de modèle basé sur les événements sur votre IAsyncResult implémentation de modèle.

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

    • Exposez le modèle basé sur les événements et le IAsyncResult modèle sur la même classe lorsque la compatibilité l’exige. Par exemple, si vous avez déjà publié une API qui utilise le IAsyncResult modèle, vous devez conserver le modèle pour la IAsyncResult compatibilité descendante.

    • Exposez le modèle basé sur les événements et le IAsyncResult modèle sur la même classe si la complexité du modèle objet résultant dépasse l’avantage de séparer les implémentations. Il est préférable d’exposer les deux modèles sur une seule classe que d’éviter d’exposer le modèle basé sur les événements.

    • Si vous devez exposer à la fois le modèle basé sur les événements et IAsyncResult le modèle sur une seule classe, utilisez EditorBrowsableAttribute défini pour Advanced marquer l’implémentation du IAsyncResult modèle comme fonctionnalité avancée. Cela indique que les environnements de conception, tels que Visual Studio IntelliSense, n’affichent pas les IAsyncResult propriétés et méthodes. Ces propriétés et méthodes sont toujours entièrement utilisables, mais le développeur travaillant via IntelliSense a une vue plus claire de l’API.

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

Bien que le modèle asynchrone basé sur les événements présente de nombreux avantages dans les scénarios mentionnés précédemment, il présente certains inconvénients, que vous devez savoir si les performances sont vos besoins les plus importants.

Il existe trois scénarios que le modèle basé sur les événements ne traite pas, ainsi que le IAsyncResult modèle :

Vous pouvez résoudre ces scénarios à l’aide du modèle basé sur les événements, mais cela est plus fastidieux que l’utilisation du IAsyncResult modèle.

Les développeurs utilisent souvent le IAsyncResult modèle pour les services qui ont généralement des exigences de performances très élevées. Par exemple, l’interrogation du scénario d’achèvement est une technique de serveur hautes performances.

En outre, le modèle basé sur les événements est moins efficace que le IAsyncResult modèle, car il crée plus d’objets, en particulier EventArgs, et parce qu’il se synchronise entre les threads.

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

  • N’exposez le IAsyncResult modèle que lorsque vous avez spécifiquement besoin d’une prise en charge pour ou IAsyncResult d’objetsWaitHandle.

  • Exposez uniquement le IAsyncResult modèle lorsque vous disposez d’une API existante qui utilise le IAsyncResult modèle.

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

  • IAsyncResult Exposez uniquement le modèle si vous avez des exigences élevées en matière de performances que vous avez vérifiées ne peuvent pas être remplies par le modèle basé sur les événements, mais que vous IAsyncResult pouvez répondre au modèle.

Voir aussi

  • Last updated on