Per visualizzare l'articolo in inglese, selezionare la casella di controllo Inglese. È possibile anche visualizzare il testo inglese in una finestra popup posizionando il puntatore del mouse sopra il testo.
Traduzione
Inglese

Deciding When to Implement the Event-based Asynchronous Pattern

 

Il modello asincrono basato su eventi consente di esporre il comportamento asincrono di una classe.  Con l'introduzione di questo modello, in .NET Framework sono ora disponibili due modelli per l'esposizione del comportamento asincrono: il modello asincrono basato sull'interfaccia System.IAsyncResult e il modello basato su eventi.  In questo argomento vengono illustrati i casi in cui è opportuno implementare entrambi i modelli.  

Per ulteriori informazioni sulla programmazione asincrona con l'interfaccia IAsyncResult, vedere Event-based Asynchronous Pattern (EAP).

In genere, è sempre opportuno esporre le funzionalità asincrone utilizzando il modello asincrono basato su eventi, se possibile.  Esistono tuttavia alcuni requisiti che il modello basato su eventi non è in grado di soddisfare.  In questi casi, può essere necessario implementare il modello IAsyncResult, oltre a quello basato su eventi.  

System_CAPS_noteNota

È raro che il modello IAsyncResult venga implementato senza che lo sia anche il modello basato su eventi.

Di seguito vengono fornite alcune indicazioni in base alle quali stabilire quando è necessario implementare il modello asincrono basato su eventi.

  • Utilizzare il modello basato su eventi come API predefinita per esporre il comportamento asincrono della classe.

  • Non esporre il modello IAsyncResult se la classe viene principalmente utilizzata in un'applicazione client, ad esempio Windows Form.

  • Esporre il modello IAsyncResult solo quando risulta necessario per soddisfare i requisiti.  È ad esempio possibile che il modello IAsyncResult debba essere esposto per motivi di compatibilità con un'API esistente.  

  • Non esporre il modello IAsyncResult senza esporre anche quello basato su eventi.

  • Se è necessario esporre il modello IAsyncResult, eseguire questa operazione come opzione avanzata.  Se ad esempio si genera un oggetto proxy, generare il modello basato su eventi per impostazione predefinita, inserendo un'opzione per la generazione del modello IAsyncResult.  

  • Compilare l'implementazione del modello basato su eventi nell'implementazione del modello IAsyncResult.

  • Evitare di esporre il modello basato su eventi e il modello IAsyncResult nella stessa classe.  Esporre il modello basato su eventi in classi di livello superiore e il modello IAsyncResult in classi di livello inferiore.  Ad esempio, confrontare il modello basato su eventi nel componente WebClient con il modello IAsyncResult nella classe HttpRequest.  

    • Esporre il modello basato su eventi e il modello IAsyncResult nella stessa classe quando necessario per motivi di compatibilità.  Se ad esempio è stata già rilasciata un'API che utilizza il modello IAsyncResult, sarà necessario mantenere il modello IAsyncResult per compatibilità con le versioni precedenti.  

    • Esporre il modello basato su eventi e il modello IAsyncResult nella stessa classe se la complessità del modello a oggetti risultante è superiore al vantaggio offerto da implementazioni separate.  È preferibile esporre entrambi i modelli in una singola classe anziché evitare di esporre il modello basato su eventi.  

    • Se è necessario esporre sia il modello basato su eventi che il modello IAsyncResult in una singola classe, utilizzare EditorBrowsableAttribute impostato su Advanced per contrassegnare l'implementazione del modello IAsyncResult come funzionalità avanzata.  In questo modo verrà indicato agli ambienti di sviluppo, ad esempio IntelliSense di Visual Studio, di non visualizzare i metodi o le proprietà di IAsyncResult.  Tali metodi e proprietà potranno comunque essere utilizzati in modo completo, ma lo sviluppatore che opera mediante IntelliSense avrà una visualizzazione più chiara dell'API.  

Il modello asincrono basato su eventi offre numerosi vantaggi negli scenari descritti in precedenza, ma presenta anche alcuni inconvenienti, di cui è necessario essere a conoscenza se le prestazioni rappresentano un requisito fondamentale.

Esistono tre scenari in cui il modello basato su eventi offre vantaggi minori rispetto al modello IAsyncResult:

È possibile operare in questi scenari utilizzando il modello basato su eventi, anche se il modello IAsyncResult risulterebbe meno complicato.

Gli sviluppatori spesso utilizzano il modello IAsyncResult per servizi che presentano in genere requisiti di prestazioni molto elevati.  Il polling per lo scenario di completamento è ad esempio un tecnica per server ad alte prestazioni.  

Inoltre, il modello basato su eventi è meno efficiente del modello IAsyncResult perché crea più oggetti, in particolare EventArgs, ed esegue la sincronizzazione attraverso i thread.

Nell'elenco riportato di seguito vengono fornite alcune indicazioni a cui attenersi se si sceglie di utilizzare il modello IAsyncResult:

  • Esporre il modello IAsyncResult solo quando è necessario disporre del supporto per l'oggetto WaitHandle o IAsyncResult.

  • Esporre il modello IAsyncResult solo quando è disponibile un'API esistente che utilizza il modello IAsyncResult.

  • Se si dispone di un'API esistente basata sul modello IAsyncResult, può essere opportuno esporre anche il modello basato su eventi nel rilascio successivo.

  • Esporre il modello IAsyncResult solo se esistono requisiti di prestazioni elevate già verificati che non possono essere soddisfatti dal modello basato su eventi, ma dal modello IAsyncResult.

Mostra: