Dynamische bestanden weergeven met Blazor in ASP.NET

0
183

Een van de vele geweldige functies van frameworks zoals Blazor en ASP.NET ( waarop het draait) is de mogelijkheid om dynamische inhoud te leveren op elk eindpunt dat uw toepassing nodig heeft. Als u downloads van gegenereerde bestanden wilt aanbieden, is dat eenvoudig te doen met een kleine configuratie.

Waarom dynamische bestanden dienen ?

In principe heb je als webserver twee opties: reageren op een verzoek met statische inhoud, zoals een HTML-pagina of JPG-bestand, of een aangepast antwoord genereren om naar de gebruiker te sturen. Blazor draait op ASP.NET, dus de ingebouwde HTTP-server ondersteunt een breed scala aan opties en zorgt voor een grote flexibiliteit.

Misschien wilt u bijvoorbeeld een JSON-bestand hosten op /images/pathname. json. Dit hoeft geen letterlijk bestand op schijf te zijn; de server kan dit verzoek interpreteren en reageren met elk type inhoud, inclusief iets onverwachts zoals een PNG-bestand. Je zou op dit verzoek kunnen reageren door enkele resultaten van een API op te halen, een antwoord op te stellen en de string terug te sturen naar de gebruiker.

Of misschien wilt u het eigenlijke bestand direct genereren. Er zijn bijvoorbeeld veel grafische bibliotheken die worden gebruikt voor het tekenen van aangepaste afbeeldingen. Je zou een van deze kunnen gebruiken om een ​​afbeelding te genereren en te reageren op het gebruikersverzoek met de gegevens, allemaal in het geheugen.

In het laatste geval kan het zinvol zijn om het antwoord in de cache op te slaan door het op schijf op te slaan en antwoorden met een echt bestand meestal. Dit kan handig zijn voor resource-intensieve bestandsgeneraties die niet zo vaak veranderen.

Instellen

Het presenteren van bestanden zoals deze is ingebouwd en vrij eenvoudig om te doen. U moet een nieuwe Razor-pagina maken, waarop Blazor draait. U kunt dit doen door met de rechtermuisknop te klikken in Visual Studio en Toevoegen > Razor-pagina.

Advertentie

Hierdoor worden twee bestanden gemaakt die in de hiërarchie aan elkaar zijn gekoppeld: Name.cshtml, die de HTML-kant van de dingen afhandelt, en Name.cshtml.cs, die het model en de eigenlijke code afhandelt. Aangezien dit geen echte webpagina zal zijn, maar een bestand, kunt u de eerste grotendeels negeren.

U moet echter het attribuut @page instellen om overeen te komen met waar u wilt dat dit bestand wordt gehost. Je zult waarschijnlijk wat wildcards willen toevoegen, wat je doet met haakjes.

In het bestand Name.cshtml.cs ziet u een aantal daadwerkelijke code die PageModel uitbreidt. De belangrijkste functie hier is OnGet(), die u waarschijnlijk wilt wijzigen in OnGetAsync() als u asynchrone verwerking uitvoert.

Je hebt drie hoofdopties van deze functie. Ten eerste, het retourneren van een PhysicalFile, dat letterlijk een bestand op schijf leest met een pad, en het naar de gebruiker stuurt met een type, optioneel met een aparte downloadnaam dan het eigenlijke pad.

Hoewel je hier waarschijnlijk bent om iets dynamisch te genereren, kan dit erg handig zijn voor caching. Als je verwerkingsfunctie het resultaat in een bestand hebt opgeslagen, kun je controleren of dat bestand bestaat voordat je het opnieuw verwerkt, en als dat het geval is, retourneer je gewoon het in de cache opgeslagen antwoord.

Advertentie

De volgende optie is het retourneren van een virtueel bestand, gegeven een bytearray. Dit is wat je voor de meeste toepassingen wilt gebruiken, omdat het volledig in het geheugen werkt en erg snel zou moeten zijn.

Afhankelijk van de codering die je probeert te gebruiken, wil je misschien om een ​​string om te zetten in een bytearray met behulp van de Encoding-helperklasse.

Encoding.UTF8.GetBytes(string);

Ten slotte kunt u rechtstreeks een inhoudsreeks retourneren, wat u ook zou moeten doen gebruiken als u de inhoud aan de gebruiker wilt tonen in plaats van een download in zijn browser te starten.

Er zijn andere opties dan deze drie, maar de rest omvat antwoorden met statuscodes, omleiden , ongeautoriseerde reacties en het weergeven van de pagina zelf.

Bestanden presenteren op basis van routes & Parameters

Dit is natuurlijk allemaal niet handig als u niet kunt reageren op verzoeken op basis van gebruikersinvoer. De twee vormen van invoer bevinden zich beide in de URL: routeringsparameters en URL-parameters. Routeringsparameters zijn wat u hebt opgegeven met behulp van jokertekens op de pagina zelf, en zijn het daadwerkelijke pad naar het bestand. URL-parameters zijn optioneel.

Het kan een beetje lastig zijn om dit uit te zoeken, maar gelukkig heb je een debugger aan je zijde, zodat je een breekpunt kunt instellen in OnGetAsync() en de hele lokale variabelenstructuur kunt bekijken .

Advertentie

U vindt onder this.PageContext.RouteData een RouteValueDictionary<string, object> waarin alle routes worden opgeslagen. Houd er rekening mee dat dit de paginaroute zelf omvat, dus als u /Download/{param} als de route gebruikt, is de param de tweede optie.

De beste manier om de parameters op te halen, is door ze op te zoeken per sleutel:

Op dezelfde manier zijn de queryparameters ook beschikbaar , zij het van een ander object. U moet toegang krijgen tot HttpContext.Request.Query, een QueryValueDictionary die de URL-parameters bevat en op vrijwel dezelfde manier werkt als de route-versie.

U bent dan vrij om deze parameters te gebruiken om zoekopdrachten uit te voeren of logica te beïnvloeden. Als u echter reacties in de cache plaatst, moet u ervoor zorgen dat uw cachevoorwaarden en zoekopdrachten ook door deze parameters worden beïnvloed, anders kunt u problemen krijgen met onverwacht cachegedrag.