L'une des nombreuses fonctionnalités intéressantes des frameworks comme Blazor et ASP.NET (sur lequel il s'exécute) est le capacité de servir du contenu dynamique à tout point de terminaison dont votre application a besoin. Si vous souhaitez servir des téléchargements de fichiers générés, c'est facile à faire avec un peu de configuration.
Pourquoi servir des fichiers dynamiques ?
Fondamentalement, vous avez deux options en tant que serveur Web : répondre à une demande avec un contenu statique, comme une page HTML ou un fichier JPG, ou générer une réponse personnalisée à envoyer à l'utilisateur. Blazor fonctionne sur ASP.NET, donc le serveur HTTP intégré prend en charge un large éventail d'options et permet une grande flexibilité.
Par exemple, vous souhaitez peut-être héberger un fichier JSON dans /images/pathname. json. Cela ne doit pas nécessairement être un fichier littéral sur le disque ; le serveur peut interpréter cette demande et répondre avec n'importe quel type de contenu, y compris quelque chose d'inattendu comme un fichier PNG. Vous pouvez répondre à cette demande en récupérant certains résultats d'une API, en construisant une réponse et en renvoyant la chaîne à l'utilisateur.
Ou peut-être souhaitez-vous générer le fichier réel à la volée. Par exemple, il existe de nombreuses bibliothèques graphiques utilisées pour dessiner des images personnalisées. Vous pouvez utiliser l'un d'entre eux pour générer une image et répondre à la demande de l'utilisateur avec les données, le tout en mémoire.
Dans ce dernier cas, il peut être judicieux de mettre en cache la réponse en la sauvegardant sur disque et répondre avec un vrai fichier la plupart du temps. Cela peut être utile pour les générations de fichiers gourmandes en ressources qui ne changent pas si souvent.
Configuration
Le service de fichiers comme celui-ci est intégré et assez simple à faire. Vous devrez créer une nouvelle page Razor, sur laquelle Blazor s'exécute. Vous pouvez le faire en cliquant avec le bouton droit dans Visual Studio et en sélectionnant Ajouter > Page Razor.
Publicité
Cela crée deux fichiers qui sont liés les uns aux autres dans la hiérarchie : Name.cshtml, qui gère le côté HTML des choses, et Name.cshtml.cs, qui gère le modèle et le code réel. Étant donné qu'il ne s'agira pas d'une page Web réelle, mais d'un fichier, vous pouvez ignorer le premier pour la plupart.
Vous devrez cependant définir l'attribut @page pour qu'il corresponde à l'endroit où vous souhaitez que ce fichier soit hébergé. Vous voudrez probablement inclure des caractères génériques, ce que vous faites avec des crochets.
Dans le fichier Name.cshtml.cs, vous verrez du code réel étendre PageModel. La fonction principale ici est OnGet(), que vous voudrez probablement changer en OnGetAsync() si vous effectuez un traitement asynchrone.
Vous avez trois options principales à partir de cette fonction. Premièrement, retourne un PhysicalFile, qui lit littéralement un fichier sur le disque avec un chemin donné, et l'envoie à l'utilisateur avec un type, éventuellement avec un nom de téléchargement différent du chemin réel.
Bien que vous soyez probablement ici pour générer quelque chose de manière dynamique, cela peut être très utile pour la mise en cache. Si votre fonction de traitement enregistre le résultat dans un fichier, vous pouvez vérifier si ce fichier existe avant de le traiter à nouveau, et si c'est le cas, renvoyer simplement la réponse mise en cache.
Publicité
L'option suivante renvoie un fichier virtuel, étant donné un tableau d'octets. C'est ce que vous voudrez utiliser pour la plupart des applications, car il fonctionne entièrement en mémoire et devrait être très rapide.
Selon l'encodage que vous essayez d'utiliser, vous voudrez peut-être pour convertir une chaîne en un tableau d'octets à l'aide de la classe d'assistance Encoding.
Encoding.UTF8.GetBytes(string);
Enfin, vous pouvez renvoyer directement une chaîne de contenu, ce que vous devez utiliser si vous souhaitez afficher le contenu à l'utilisateur plutôt que de déclencher un téléchargement dans son navigateur.
Il existe d'autres options que ces trois-là, mais le reste implique de répondre avec des codes d'état, de rediriger, de réponses non autorisées et de rendre la page elle-même.
< h2 role="heading" aria-level="2">Servir des fichiers basés sur des routes & Paramètres
Bien sûr, rien de tout cela n'est utile si vous ne pouvez pas répondre aux demandes basées sur les entrées de l'utilisateur. Les deux formes d'entrée sont toutes deux dans l'URL : les paramètres de routage et les paramètres d'URL. Les paramètres de routage sont ce que vous avez spécifié à l'aide de caractères génériques dans la page elle-même et constituent le chemin d'accès réel au fichier. Les paramètres d'URL sont facultatifs.
Il peut être difficile de comprendre cela, mais heureusement, vous avez un débogueur à vos côtés, vous pouvez donc définir un point d'arrêt dans OnGetAsync() et afficher l'intégralité de l'arborescence des variables locales .
Publicité
Vous trouverez, sous this.PageContext.RouteData, un RouteValueDictionary<string, object> qui stocke tous les itinéraires. Notez que cela inclut la route de la page elle-même, donc si vous avez utilisé /Download/{param} comme route, le paramètre sera la deuxième option.
La meilleure façon de récupérer les paramètres est de les rechercher par clé :
De même, les paramètres de requête sont également disponibles, mais à partir d'un objet différent. Vous devrez accéder à HttpContext.Request.Query, qui est un QueryValueDictionary contenant les paramètres d'URL et fonctionne de la même manière que celui de la route.
Vous êtes ensuite libre d'utiliser ces paramètres pour effectuer des recherches ou affecter la logique. Cependant, si vous mettez en cache des réponses, vous voudrez vous assurer que vos conditions de cache et vos recherches sont également affectées par ces paramètres, ou vous pourriez rencontrer des problèmes avec des comportements de mise en cache inattendus.