IHttpActionResult vs async Aufgabe <IHttpActionResult>

Question

Die meisten Web API 2.0-Methoden, die ich gesehen habe, geben IHttpActionResult, die als Schnittstelle definiert ist, definiert einen Befehl, der eine System.Net.Http.HttpResponseMessage asynchron erstellt.

Ich bin ein wenig verwirrt darüber, was passiert, wenn eine Methode async Task<IHttpActionResult> zurückgibt.

Warum würden Sie einen über den anderen verwenden? Oder sind diese funktional identisch - ist IHttpActionResult schon asynchron?

Answer 1

Der Unterschied zwischen IHttpActionResult und async Task<IHttpActionResult> Verwendung ist, ob eines der Code die Funktion async und await nutzt. Viele Bibliotheken wie Entity Framework bieten async Versionen von Methoden (z. B. SaveChangesAsync), die eine leichte Leistungssteigerung bieten. Es gibt jedoch viele Probleme bei der Verwendung von async mit Web-API. Wenn Sie also nicht viele der Eigenheiten verstehen, ist es ratsam, sich an die synchrone API zu halten.

Steven Cleary hat viele Informationen über his blog über die Idiosynkrasien von async und await. Um zu beginnen, rate ich zu betrachten Don't block on async code.

Answer 2

Ihre Aktion gibt möglicherweise eine IHttpActionResult zurück, die die Aktion asynchron ausführt, wenn das Framework seine ExecuteAsync aufruft.

Wenn Sie jedoch vor dem Erstellen und Zurückgeben des Ergebnisses zuerst einige andere asynchrone Aufrufe durchführen müssen, müssen Sie die Signatur in async Task<IHttpActionResult> ändern. Das ist alles.

Wenn Ihr Controller-Aktionscode await nicht verwendet, können Sie zurück zur einfacheren Signatur wechseln. Das von Ihnen zurückgegebene Ergebnis ist jedoch immer noch asynchron.

Um klar zu sein, verwenden Sie in beiden Fällen asynchronen Code.

Der Leistungsvorteil besteht darin, dass - sofern alle Aufrufe der tiefsten Ebene asynchron sind - ein Webserver Thread während der Datenträger- oder Netzwerk-E/A nicht blockiert wird und Ihr Server mehr Anfragen mit weniger Ressourcen verarbeiten kann.

Denken Sie sorgfältig, bevor Sie Wait oder Result für eine Aufgabe aufrufen, oder erstellen Sie selbst eine Aufgabe in ASP.NET-Code.

Zwei berechtigte Gründe zur Hand-Code, vorsätzliches Multi-Threading oder Parallelität für Web-Server-Code ist:

• , wenn es empfängt minimalen Verkehr, sondern führt Rechenarbeit, einen Anruf so oft jeden eine Berechnung zu überfahren Daten und Sie möchten alle 16 Kerne verwenden.
• Wenn Sie> 1 gleichzeitige Aufrufe von Datenbank-Shards oder> 1 anderen Diensten machen, würden Sie eine Aufgabe für jede Shard-Abfrage starten und auf alle warten.