Servindo arquivos dinâmicos com Blazor em ASP.NET

Um dos muitos recursos excelentes de estruturas como Blazor e ASP. NET (nos quais são executados) é a capacidade de servir conteúdo dinâmico em qualquer ponto de extremidade de que seu aplicativo precise. Se você deseja disponibilizar downloads de arquivos gerados, é fácil de fazer com um pouco de configuração.

Por que veicular arquivos dinâmicos?

Basicamente, você tem duas opções como servidor da web: responder a uma solicitação com conteúdo estático, como uma página HTML ou arquivo JPG, ou gerar uma resposta personalizada para enviar ao usuário. O Blazor é executado em ASP. NET, portanto, o servidor HTTP integrado oferece suporte a uma ampla gama de opções e permite grande flexibilidade.

Por exemplo, talvez você queira hospedar um arquivo JSON em /images/pathname. json. Não precisa ser um arquivo literal no disco; o servidor pode interpretar esta solicitação e responder com qualquer tipo de conteúdo, incluindo algo inesperado como um arquivo PNG. Você pode responder a essa solicitação buscando alguns resultados de uma API, construindo uma resposta e enviando a string de volta ao usuário.

Ou talvez você &’ queira gerar o arquivo real imediatamente. Por exemplo, existem muitas bibliotecas gráficas usadas para desenhar imagens personalizadas. Você pode usar um deles para gerar uma imagem e responder à solicitação do usuário com os dados, tudo na memória.

No último caso, pode fazer sentido armazenar a resposta em cache, salvando-a no disco e respondendo com um arquivo real na maioria das vezes. Isso pode ser útil para gerações de arquivos que consomem muitos recursos e que não mudam com tanta frequência.

Configurando

Servir arquivos como este é integrado e muito simples de fazer. Você precisará criar uma nova página do Razor, na qual o Blazor é executado. Você pode fazer isso clicando com o botão direito no Visual Studio e selecionando Adicionar > Página do Razor.

Publicidade

Isso cria dois arquivos que estão vinculados um ao outro na hierarquia: Name. cshtml, que lida com o lado HTML das coisas, e Name. cshtml. cs, que lida com o modelo e o código real. Como esta não será uma página da web real, apenas um arquivo, você pode ignorar o primeiro na maior parte.

No entanto, você precisará definir o atributo @page para corresponder ao local onde deseja que este arquivo seja hospedado. Provavelmente, você desejará incluir alguns caracteres curinga, o que é feito com colchetes.

No arquivo Name. cshtml. cs, você &’ verá algum código real estendendo o PageModel. A função principal aqui é OnGet (), que provavelmente você desejará alterar para OnGetAsync () se estiver fazendo qualquer processamento assíncrono.

Você tem três opções principais para esta função. Primeiro, está retornando um PhysicalFile, que literalmente lê um arquivo no disco dado um caminho e o envia ao usuário com um tipo, opcionalmente com um nome de download separado do caminho real.

Embora você provavelmente esteja aqui para gerar algo dinamicamente, isso pode ser muito útil para o armazenamento em cache. Se sua função de processamento salvar o resultado em um arquivo, poderá verificar se esse arquivo existe antes de processá-lo novamente e, se existir, basta retornar a resposta em cache.

Publicidade

A próxima opção é retornar um arquivo virtual, dado uma matriz de bytes. Isso é o que você deseja usar para a maioria dos aplicativos, já que funciona inteiramente na memória e deve ser muito rápido.

Dependendo de qual codificação você está tentando usar, convém converter uma string em uma matriz de bytes usando a classe auxiliar de codificação.

 Encoding. UTF8. GetBytes (string); 

Por último, você pode retornar uma string de conteúdo diretamente, que é o que você deve usar se quiser exibir o conteúdo para o usuário em vez de acionar um download no navegador.

Existem outras opções além dessas três, mas o resto envolve responder com códigos de status, redirecionar, respostas não autorizadas e renderizar a própria página.

Exibição de arquivos com base em rotas & Parâmetros

Claro, nada disso é útil se você não puder responder às solicitações com base na entrada do usuário. As duas formas de entrada estão ambas no URL: parâmetros de roteamento e parâmetros de URL. Os parâmetros de roteamento são os que você especificou usando curingas na própria página e são o caminho real para o arquivo. Os parâmetros de URL são opcionais.

Descobrir isso pode ser um pouco chato, mas felizmente você tem um depurador ao seu lado, então você pode definir um ponto de interrupção em OnGetAsync () e visualizar toda a variável local árvore.

Publicidade

Você encontrará, em this. PageContext. RouteData, um RouteValueDictionary < string, object > que armazena todas as rotas. Observe que isso inclui a rota da página em si, portanto, se você usou / Download / como a rota, o parâmetro será a segunda opção.

A melhor maneira de buscar os parâmetros é pesquisá-los por chave:

Da mesma forma, os parâmetros de consulta também estão disponíveis, embora de um objeto diferente. Você precisará acessar HttpContext. Request. Query, que é um QueryValueDictionary que contém os parâmetros de URL e funciona da mesma maneira que o da rota.

Você está então livre para usar esses parâmetros para realizar pesquisas ou afetar a lógica. Porém, se estiver armazenando respostas em cache, você desejará ter certeza de que as condições e pesquisas de seu cache são afetadas por esses parâmetros também, ou você pode ter problemas com comportamentos de cache inesperados.