IHttpActionResult vs tâche asynchrone <IHttpActionResult>
La plupart des méthodes de l'API Web 2.0 que j'ai vues retournent IHttpActionResult, qui est définie comme une interface qui "définit une commande qui crée de manière asynchrone un System.Net.Http.HttpResponseMessage".
Je suis un peu confus sur ce qui se passe quand une méthode retourne async Task<IHttpActionResult>.
Pourquoi voudriez-vous utiliser l'un sur l'autre? Ou sont-ils fonctionnellement identiques - n'est-ce pas IHttpActionResult déjà asynchrone?
La différence entre l'utilisation de IHttpActionResult et async Task<IHttpActionResult> indique si l'un de vos codes utilise les fonctions async et await. De nombreuses bibliothèques comme Entity Framework fournissent async des versions de méthodes (par exemple SaveChangesAsync) qui fournissent une légère augmentation des performances. Cependant, il y a des pièges à utiliser async avec l'API Web, donc à moins que vous ne compreniez bon nombre des particularités, il est prudent de s'en tenir à l'API synchrone.
Steven Cleary a beaucoup d'informations sur son blog sur les particularités de async et await. Pour commencer, je vous conseille de regarder Ne pas bloquer sur le code asynchrone .
Votre action peut renvoyer un IHttpActionResult qui exécute l'action de manière asynchrone lorsque le framework appelle son ExecuteAsync.
Mais si vous devez d'abord effectuer d'autres appels asynchrones avant de créer et de renvoyer le résultat, vous êtes alors obligé de changer la signature en async Task<IHttpActionResult>. C'est tout.
Si le code d'action de votre contrôleur n'utilise pas await, vous pouvez revenir à la signature plus simple. Cependant, le résultat que vous retournez sera toujours asynchrone.
Pour être clair, dans les deux cas, vous utilisez du code asynchrone.
L'avantage en termes de performances est que - à condition que tous les appels au niveau le plus profond soient asynchrones - un thread de serveur Web n'est pas bloqué pendant les E/S disque ou réseau, votre serveur peut traiter plus de demandes avec moins de ressources.
Réfléchissez bien avant d'appeler Wait ou Result sur une tâche, ou de créer vous-même une tâche dans le code ASP.NET.
Deux raisons légitimes de coder manuellement, le multithread intentionnel ou le parallélisme pour le code du serveur Web sont:
- lorsqu'il reçoit un trafic minimal mais effectue un travail de calcul, un appel de temps en temps pour exécuter un calcul sur des données et vous souhaitez utiliser les 16 cœurs.
- lorsque vous effectuez> 1 appels simultanés à des fragments de base de données ou> 1 autres services, vous devez effectuer une tâche pour chaque requête de fragment à l'avance et les attendre tous.