Fichier de téléchargement de L'API Web 2 à L'aide de la tâche async
j'ai besoin d'écrire une méthode comme ci-dessous pour retourner un document texte (.txt, pdf,.doc. ,docx, etc) Bien qu'il y ait de bons exemples d'affichage de fichier dans L'API Web 2.0 sur le web , Je n'ai pas pu en trouver un pour en télécharger un. (Je sais comment le faire dans HttpResponseMessage.)
public async Task<IHttpActionResult> GetFileAsync(int FileId)
{
//just returning file part (no other logic needed)
}
ce qui précède doit-il être asynchrone? Je ne cherche qu'à retourner stream. (C'est bon?)
plus important encore avant que je ne finisse par faire le travail d'une façon ou d'une autre otther, je voulais savoir quelle est la "bonne" façon de faire ce genre de travail... (c'est pourquoi les approches et les techniques qui en font mention seraient grandement appréciées).. grâce.
2 réponses
Droit, pour votre scénario ci-dessus, l'action n'a pas besoin de retourner un async résultat de l'action. Ici, je suis entrain de créer un personnalisé IHttpActionResult. Vous pouvez vérifier mes commentaires dans le code ci-dessous ici.
public IHttpActionResult GetFileAsync(int fileId)
{
// NOTE: If there was any other 'async' stuff here, then you would need to return
// a Task<IHttpActionResult>, but for this simple case you need not.
return new FileActionResult(fileId);
}
public class FileActionResult : IHttpActionResult
{
public FileActionResult(int fileId)
{
this.FileId = fileId;
}
public int FileId { get; private set; }
public Task<HttpResponseMessage> ExecuteAsync(CancellationToken cancellationToken)
{
HttpResponseMessage response = new HttpResponseMessage();
response.Content = new StreamContent(File.OpenRead(@"<base path>" + FileId));
response.Content.Headers.ContentDisposition = new ContentDispositionHeaderValue("attachment");
// NOTE: Here I am just setting the result on the Task and not really doing any async stuff.
// But let's say you do stuff like contacting a File hosting service to get the file, then you would do 'async' stuff here.
return Task.FromResult(response);
}
}
Les méthodes sont asynchrones si elles renvoient un objet de tâche, pas parce qu'elles sont décorées avec un mot-clé asynchrone. async est seulement un sucre syntaxique pour remplacer cette syntaxe qui peut devenir assez complexe quand il y a plus de tâches combinées ou plus de continuations:
public Task<int> ExampleMethodAsync()
{
var httpClient = new HttpClient();
var task = httpClient.GetStringAsync("http://msdn.microsoft.com")
.ContinueWith(previousTask =>
{
ResultsTextBox.Text += "Preparing to finish ExampleMethodAsync.\n";
int exampleInt = previousTask.Result.Length;
return exampleInt;
});
return task;
}
échantillon Original avec async: http://msdn.microsoft.com/en-us/library/hh156513.aspx
asynchrone nécessite toujours attendre, ce qui est appliquée par le compilateur.
les Deux implémentations sont asynchroous, la seule différence est que async+wait remplace le Continu par du code "synchrone".
tâche de retour des méthodes de controller ce que do IO (99% des cas que j'estime) est important parce que l'exécution peut suspendre et réutiliser le thread de requête pour servir d'autres requêtes pendant que l'opération IO est en cours. Cela réduit les chances de manquer de filetage de piscine. Voici un article sur le sujet: http://www.asp.net/mvc/overview/performance/using-asynchronous-methods-in-aspnet-mvc-4
donc la réponse à votre question " Est-ce que ce qui précède doit être async à tous? Je ne cherche qu'à retourner stream. (C'est bon?) ", c'est qu'il ne fait pas de différence à l'appelant, il ne change la façon dont votre code ressemble (mais pas comment ça marche).