IHttpActionResult vs async Compito <IHttpActionResult>

Question

La maggior parte dei metodi Web API 2.0 che ho visto restituiscono IHttpActionResult, che è definita come un'interfaccia che "definisce un comando che crea in modo asincrono System.Net.Http.HttpResponseMessage".

Sono un po 'confuso su cosa sta succedendo quando un metodo sta restituendo async Task<IHttpActionResult>.

Perché dovresti usare uno sull'altro? O questi sono funzionalmente identici - non è IHttpActionResult già asincrono?

Answer 1

La differenza tra l'utilizzo di IHttpActionResult e async Task<IHttpActionResult> è se qualsiasi del codice utilizza la funzione async e await. Molte librerie come Entity Framework forniscono versioni di metodi async (ad esempio SaveChangesAsync) che forniscono un leggero aumento delle prestazioni. Tuttavia, vi sono dei rischi nell'utilizzo di API Web async, quindi a meno che non comprendiate molte delle idiosincrasie, è prudente attenersi all'API sincrona.

Steven Cleary ha un sacco di informazioni su his blog sulle idiosincrasie di async e await. Per iniziare ti consiglio di guardare Don't block on async code.

Answer 2

L'azione può restituire un IHttpActionResult che esegue l'azione in modo asincrono quando il framework chiama il suo ExecuteAsync.

Tuttavia, se prima è necessario effettuare altre chiamate asincrone prima di creare e restituire il risultato, è necessario modificare la firma in async Task<IHttpActionResult>. Questo è tutto.

Se il codice di azione del controller non utilizza await, è possibile tornare alla firma più semplice. Tuttavia, il risultato che si restituirà sarà ancora asincrono.

Per essere chiari, in entrambi i casi si utilizza codice asincrono.

Il vantaggio è che le prestazioni - a condizione che tutte le chiamate al livello più profondo sono asincrona - un thread del server web non è bloccata durante disco o di rete di I/O, il server può gestire più richieste con un minor numero di risorse.

Pensare attentamente prima di chiamare Wait o Result in un'attività o creare un'attività autonomamente all'interno del codice ASP.NET.

Due motivi legittimi a portata di mano-codice, intenzionale multi-threading o il parallelismo per il codice del server web sono:

• quando riceve traffico minimo, ma svolge un lavoro computazionale, una chiamata ogni tanto per eseguire un calcolo su dati e si desidera utilizzare tutti i 16 core.
• quando si effettuano> 1 chiamate simultanee a frammenti di database o altri 1 servizi, si dovrebbe eseguire un'attività per ciascuna query shard in primo piano e attendere tutti.