Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Il modello asincrono basato su eventi fornisce un modello per esporre il comportamento asincrono di una classe. Con l'introduzione di questo modello, .NET definisce due modelli per esporre il comportamento asincrono: il modello asincrono basato sull'interfaccia System.IAsyncResult e il modello basato su eventi. Questo articolo descrive quando è opportuno implementare entrambi i modelli.
Per altre informazioni sulla programmazione asincrona con l'interfaccia IAsyncResult , vedere Modello di programmazione asincrona (APM).
Principi generali
In generale, è consigliabile esporre le funzionalità asincrone usando il modello asincrono basato su eventi quando possibile. Esistono tuttavia alcuni requisiti che il modello basato su eventi non può soddisfare. In questi casi, potrebbe essere necessario implementare il IAsyncResult modello oltre al modello basato su eventi.
Annotazioni
È raro che il IAsyncResult modello venga implementato senza che venga implementato anche il modello basato su eventi.
Istruzioni
L'elenco seguente descrive le linee guida per quando è necessario implementare il modello asincrono basato su eventi:
Usare il modello basato su eventi come API predefinita per esporre il comportamento asincrono per la classe.
Non esporre il IAsyncResult modello quando la classe viene usata principalmente in un'applicazione client, ad esempio Windows Form.
Esporre il IAsyncResult modello solo quando è necessario per soddisfare i requisiti. Ad esempio, la compatibilità con un'API esistente potrebbe richiedere di esporre il IAsyncResult modello.
Non esporre il IAsyncResult modello senza esporre anche il modello basato su eventi.
Se è necessario esporre il IAsyncResult modello, eseguire questa operazione come opzione avanzata. Ad esempio, se si genera un oggetto proxy, generare il modello basato su eventi come impostazione predefinita, con un'opzione per generare il modello IAsyncResult.
Costruisci la tua implementazione del modello basata su eventi sulla tua implementazione del modello IAsyncResult.
Evitare di esporre sia il modello basato su eventi che il IAsyncResult modello nella stessa classe. Esporre il modello basato su eventi su classi "di livello superiore" e il IAsyncResult modello su classi "di livello inferiore". Ad esempio, confrontare il modello basato su eventi sul WebClient componente con il IAsyncResult modello nella HttpRequest classe .
Esporre il modello basato su eventi e il IAsyncResult modello nella stessa classe quando è necessaria la compatibilità. Ad esempio, se è già stata rilasciata un'API che usa il IAsyncResult modello, è necessario mantenere il IAsyncResult modello per la compatibilità con le versioni precedenti.
Esporre il modello basato su eventi e il IAsyncResult modello nella stessa classe se la complessità del modello a oggetti risultante supera il vantaggio di separare le implementazioni. È preferibile esporre entrambi i modelli in una singola classe rispetto a evitare di esporre il modello basato su eventi.
Se è necessario esporre sia il modello basato su eventi sia il modello IAsyncResult in una singola classe, usare EditorBrowsableAttribute impostato su Advanced per contrassegnare l'implementazione del modello IAsyncResult come funzionalità avanzata. Ciò indica agli ambienti di progettazione, ad esempio Visual Studio IntelliSense, di non visualizzare le proprietà e i IAsyncResult metodi. Queste proprietà e metodi sono ancora completamente utilizzabili, ma lo sviluppatore che usa IntelliSense ha una visione più chiara dell'API.
Criteri per l'esposizione del modello IAsyncResult oltre al modello basato su eventi
Anche se il modello asincrono basato su eventi offre molti vantaggi negli scenari menzionati in precedenza, presenta alcuni svantaggi, che è necessario tenere presente se le prestazioni sono i requisiti più importanti.
Esistono tre scenari che il modello basato su eventi non risolve e il IAsyncResult modello:
Blocco dell'attesa su uno IAsyncResult
Blocco dell'attesa su molti IAsyncResult oggetti
Interrogazione per il completamento di IAsyncResult
È possibile risolvere questi scenari usando il modello basato su eventi, ma questa operazione è più complessa rispetto all'uso del IAsyncResult modello.
Gli sviluppatori usano spesso il IAsyncResult modello per i servizi che in genere hanno requisiti di prestazioni molto elevati. Ad esempio, la tecnica di polling per lo scenario di completamento è una tecnica server ad alte prestazioni.
Inoltre, il modello basato su eventi è meno efficiente del IAsyncResult modello perché crea più oggetti, in particolare EventArgs, e perché si sincronizza tra thread.
L'elenco seguente mostra alcuni consigli da seguire se si decide di usare il IAsyncResult modello:
Esporre il modello IAsyncResult solo quando è necessario supportare specificamente oggetti WaitHandle o IAsyncResult.
Esporre il IAsyncResult modello solo quando si dispone di un'API esistente che usa il IAsyncResult modello .
Se si dispone di un'API esistente basata sul IAsyncResult modello, è consigliabile esporre anche il modello basato su eventi nella versione successiva.
Utilizzare il modello IAsyncResult solo se si dispone di requisiti di prestazioni elevati che avete verificato non possano essere soddisfatti dal modello basato su eventi, ma possano essere soddisfatti dal modello IAsyncResult.
Vedere anche
- Procedura: Implementare un componente che supporta il modello asincrono basato su eventi
- Event-based Asynchronous Pattern (EAP) (Modello asincrono basato su eventi, EAP)
- Implementazione del modello asincrono basato su eventi
- Procedure consigliate per l'implementazione del modello asincrono basato su eventi
- Panoramica del modello asincrono basato su eventi