Delen via

Bepalen wanneer het Asynchrone patroon op basis van gebeurtenissen moet worden geïmplementeerd

  • Artikel

Het Asynchrone patroon op basis van gebeurtenissen biedt een patroon voor het blootstellen van het asynchrone gedrag van een klasse. Met de introductie van dit patroon definieert .NET twee patronen voor het blootstellen van asynchroon gedrag: het asynchrone patroon op basis van de System.IAsyncResult interface en het patroon op basis van gebeurtenissen. In dit artikel wordt beschreven wanneer u beide patronen kunt implementeren.

Zie Asynchroon programmeermodel (APM) voor meer informatie over asynchrone programmering met de IAsyncResult interface.

Algemene principes

Over het algemeen moet u asynchrone functies beschikbaar maken met behulp van het Asynchrone patroon op basis van gebeurtenissen, indien mogelijk. Er zijn echter enkele vereisten waaraan het patroon op basis van gebeurtenissen niet kan voldoen. In die gevallen moet u mogelijk het IAsyncResult patroon naast het patroon op basis van gebeurtenissen implementeren.

Notitie

Het is zeldzaam dat het IAsyncResult patroon wordt geïmplementeerd zonder dat het patroon op basis van gebeurtenissen ook wordt geïmplementeerd.

Richtlijnen

In de volgende lijst worden de richtlijnen beschreven voor het implementeren van Asynchroon Asynchroon patroon op basis van gebeurtenissen:

  • Gebruik het patroon op basis van gebeurtenissen als de standaard-API om asynchroon gedrag voor uw klasse beschikbaar te maken.

  • Maak het IAsyncResult patroon niet beschikbaar wanneer uw klasse voornamelijk wordt gebruikt in een clienttoepassing, bijvoorbeeld Windows Forms.

  • Maak het IAsyncResult patroon alleen beschikbaar wanneer het nodig is om aan uw vereisten te voldoen. Compatibiliteit met een bestaande API kan bijvoorbeeld vereisen dat u het IAsyncResult patroon beschikbaar maakt.

  • Maak het IAsyncResult patroon niet beschikbaar zonder ook het patroon op basis van gebeurtenissen weer te geven.

  • Als u het IAsyncResult patroon moet weergeven, doet u dit als een geavanceerde optie. Als u bijvoorbeeld een proxyobject genereert, genereert u standaard het patroon op basis van gebeurtenissen, met een optie om het IAsyncResult patroon te genereren.

  • Bouw de implementatie van uw patroon op basis van gebeurtenissen op basis van uw IAsyncResult patroon.

  • Vermijd het blootstellen van zowel het patroon op basis van gebeurtenissen als het IAsyncResult patroon in dezelfde klasse. Maak het patroon op basis van gebeurtenissen beschikbaar op klassen op een hoger niveau en het IAsyncResult patroon voor klassen op lager niveau. Vergelijk bijvoorbeeld het patroon op basis van gebeurtenissen op het WebClient onderdeel met het IAsyncResult patroon in de HttpRequest klasse.

    • Maak het patroon op basis van gebeurtenissen en het IAsyncResult patroon beschikbaar voor dezelfde klasse wanneer dit nodig is voor compatibiliteit. Als u bijvoorbeeld al een API hebt uitgebracht die gebruikmaakt van het IAsyncResult patroon, moet u het IAsyncResult patroon voor achterwaartse compatibiliteit behouden.

    • Maak het patroon op basis van gebeurtenissen en het IAsyncResult patroon beschikbaar voor dezelfde klasse als de resulterende objectmodelcomplexiteit opweegt tegen het voordeel van het scheiden van de implementaties. Het is beter om beide patronen beschikbaar te maken voor één klasse dan om te voorkomen dat het patroon op basis van gebeurtenissen zichtbaar wordt.

    • Als u zowel het patroon IAsyncResult als het patroon op basis van gebeurtenissen voor één klasse moet weergeven, gebruikt EditorBrowsableAttribute u deze optie om de implementatie van het IAsyncResult patroon als een geavanceerde functie te Advanced markeren. Dit geeft aan om omgevingen te ontwerpen, zoals Visual Studio IntelliSense, om de IAsyncResult eigenschappen en methoden niet weer te geven. Deze eigenschappen en methoden zijn nog steeds volledig bruikbaar, maar de ontwikkelaar die via IntelliSense werkt, heeft een duidelijkere weergave van de API.

Criteria voor het weergeven van het IAsyncResult-patroon naast het patroon op basis van gebeurtenissen

Hoewel het Asynchrone patroon op basis van gebeurtenissen veel voordelen heeft in het kader van de eerder genoemde scenario's, heeft het wel enkele nadelen, waar u rekening mee moet houden als de prestaties uw belangrijkste vereiste zijn.

Er zijn drie scenario's waarbij het patroon op basis van gebeurtenissen niet en het IAsyncResult patroon niet wordt aangepakt:

U kunt deze scenario's oplossen met behulp van het patroon op basis van gebeurtenissen, maar dit is lastiger dan het gebruik van het IAsyncResult patroon.

Ontwikkelaars gebruiken vaak het IAsyncResult patroon voor services die doorgaans zeer hoge prestatievereisten hebben. Het pollingscenario voor voltooiing is bijvoorbeeld een krachtige servertechniek.

Daarnaast is het patroon op basis van gebeurtenissen minder efficiënt dan het IAsyncResult patroon, omdat er meer objecten worden gemaakt, met name EventArgsomdat het synchroniseert tussen threads.

In de volgende lijst ziet u enkele aanbevelingen die u moet volgen als u besluit het IAsyncResult patroon te gebruiken:

  • Maak het IAsyncResult patroon alleen beschikbaar wanneer u specifiek ondersteuning voor WaitHandle of IAsyncResult objecten nodig hebt.

  • Maak het IAsyncResult patroon alleen beschikbaar wanneer u een bestaande API hebt die gebruikmaakt van het IAsyncResult patroon.

  • Als u een bestaande API hebt op basis van het IAsyncResult patroon, kunt u overwegen ook het patroon op basis van gebeurtenissen weer te geven in uw volgende release.

  • Alleen het patroon beschikbaar maken IAsyncResult als u hoge prestatievereisten hebt die u hebt geverifieerd, kan niet worden voldaan aan het patroon op basis van gebeurtenissen, maar kan worden voldaan aan het IAsyncResult patroon.

Zie ook