ASP.NET Core: dicas úteis para o dia a dia de um Desenvolvedor - Parte 3
Neste novo post continuo a série de dicas úteis para o dia a dia de Desenvolvedores ASP.NET Core. Caso ainda não tenha consultado os 2 primeiros artigos ou, até mesmo, gostaria de revê-los acesse os links a seguir:
ASP.NET Core: dicas úteis para o dia a dia de um Desenvolvedor - Parte 1
ASP.NET Core: dicas úteis para o dia a dia de um Desenvolvedor - Parte 2
Se você chegou até aqui e tem interesse em conhecer mais sobre o desenvolvimento de soluções Web utilizando o Azure, aproveito este espaco para mais um convite… Que tal aprender mais sobre a nuvem Microsoft, em um workshop que acontecerá durante um sábado (dia 21/09) em São Paulo Capital e implementando na prática um case que combina o uso de tecnologias como Azure App Service, Azure SQL, Azure Storage, Azure Functions e Application Insights? Acesse então o link a seguir para efetuar sua inscrição com um desconto especial: http://bit.ly/anp-dicas-aspnet
Removendo valores nulos do retorno de APIs REST
Ao utilizar bancos de dados relacionais, sobretudo bases de sistemas legados, é extremamente comum que diversos campos retornados por uma consulta apresentem conteúdo nulo.
Em se tratando do retorno de um volume grande dessas informações a partir de uma API REST, a presença de inúmeros campos nulos certamente produzirá um impacto na transmissão de dados. Uma solução neste caso seria a remoção de tais valores nulos, contribuindo assim para uma redução no tamanho das respostas produzidas pela API considerada.
Já abordei este tipo de prática no seguinte artigo:
ASP.NET Core: removendo valores nulos no retorno de uma API
Este tipo de ajuste pode ser realizado tanto a nível de projeto, através do método AddJsonOptions em ConfigureServices na classe Startup:
Como através do uso do tipo JsonResult (namespace Microsoft.AspNetCore.Mvc), configurando também aqui a propriedade NullValueHandling para que ignore valores nulos. É o que demonstra o método GetJsonProdutos na listagem a seguir:
A seguir temos um resultado obtido ao se empregar esta técnica (os valores foram registrados por meio do utilitário Fiddler), com uma redução bastante significativa no tamanho da resposta gerada:
Associando a execução de um middleware a uma Action ou Controller específico
Middlewares representam um dos pilares da arquitetura sob a qual o ASP.NET Core foi construído, permitindo adicionar novos comportamentos ou, até mesmo, customizar o funcionamento de uma aplicação baseada nesta plataforma.
O uso mais comum de uma estrutura desse tipo consiste na sua ativação a partir da classe Startup, como indicado no exemplo a seguir envolvendo uma chamada ao método UseResponseCompression:
Esse ajuste ativará a compressão para todas as respostas produzidas pela aplicação (uma API REST neste exemplo), empregando para isto o padrão GZip. Mas e se precisássemos aplicar esta técnica apenas a um Controller ou Action específica dentro do projeto em questão?
A resposta para esta pergunta passa pela codificação de uma classe com um método chamado Configure, com este último recebendo como parâmetro uma instância do tipo IApplicationBuilder (namespace Microsoft.AspNetCore.Builder) e acionando a partir desta referência o método responsável pela ativação de um middleware.
Na próxima listagem temos um exemplo desta implementação envolvendo o tipo CompressaoGZipPipeline, o qual invocará em Configure o método UseResponseCompression. Importante destacar que o middleware desejado não deverá ser acionado a partir da classe Startup.
A Action ou Controller em que será aplicado o middleware precisará ser marcada com o atributo MiddlewareFilter (CompressaoGZipPipeline), recebendo como parâmetro a classe definida no passo anterior . É o que demonstra a listagem a seguir, em que MiddlewareFilter foi associado ao método GetComCompressao:
Outros exemplos envolvendo a utilização e, até mesmo, a implementação de middlewares customizados podem ser encontrados na seguinte gravação de um evento online recente do Canal .NET:
Utilizando ActionResult<T> no retorno de APIs REST
Uma das novidades integrando o ASP.NET Core 2.1 foi a classe ActionResult<T>: essa estrutura simplifica a implementação de Actions em APIs REST permitindo tanto o retorno de um objeto, quanto de uma mensagem de erro sem que isto implique na necessidade de transformações adicionais.
Antes deste recurso seríamos obrigados a empregar a interface IActionResult, precisando ainda transformar um resultado por meio de uma instância do tipo ObjectResult:
Com ActionResult<T> essa transformação não é mais necessária, o que contribui para um código mais simplificado (como indicado na próxima listagem):
Também abordei o uso de ActionResult<T> no seguinte artigo:
ASP.NET Core 2.1: utilizando ActionResult<T> no retorno de APIs
Retornando XML em APIs REST
Embora o formato JSON tenha se tornado um padrão de mercado, há ainda a possibilidade de surgimento de demandas relacionadas à integração com sistemas legados e que necessitem que as APIs REST envolvidas retornem suas respostas em XML.
No artigo a seguir demonstrei como habilitar este padrão como retorno em APIs REST criadas com o ASP.NET Core:
ASP.NET Core: retornando XML em APIs REST
Ativar a produção de respostas empregando XML requer que o método AddXmlSerializerFormatters seja acionado na classe Startup em ConfigureServices:
Requisições enviadas à API devem possuir o header Accept com o seu valor configurado como application/xml:
Cache com Redis
Embora usual, implementações empregando cache em memória representam um sério problema durante a tentativa de se escalar uma aplicação Web. Requisições enviadas a diferentes instâncias do projeto, cada uma com seu próprio cache, resultarão em estados inválidos e consequentes falhas.
O Redis, solução NoSQL open source, é uma alternativa performática e capaz de solucionar com eficiência a questão do cache em cenários que envolvam escalabilidade. Funcionando como um repositório centralizado, a utilização do Redis pode ser facilmente habilitada em uma aplicação ASP.NET Core.
Para isto será necessário adicionar o package Microsoft.Extensions.Caching.Redis ao projeto que fará uso do Redis, bem como acionar o método AddDistributedRedisCache a fim de configurar o acesso a uma instância deste NoSQL em ConfigureServices (classe Startup):
Instâncias de IDistributedCache (namespace Microsoft.Extensions.Caching.Distributed) poderão então ser obtidas via injeção de dependências, permitindo assim a interação com o servidor do Redis:
