ASP.NET Core: dicas úteis para o dia a dia de um Desenvolvedor - Parte 5
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 4 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
ASP.NET Core: dicas úteis para o dia a dia de um Desenvolvedor - Parte 3
ASP.NET Core: dicas úteis para o dia a dia de um Desenvolvedor - Parte 4
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
Criando classes e interfaces no Visual Studio Code com C# Extensions
Como gerar novos arquivos .cs com o “esqueleto” de classes e interfaces constitui uma dúvida bastante recorrente entre Desenvolvedores que implementam soluções em ASP.NET/.NET Core com o Visual Studio Code. As C# Extensions simplificam bastante este processo, conforme é possível observar na classe gerada na imagem a seguir:
No artigo a seguir estão detalhes sobre como ativar e utilizar os recursos oferecidos pelas C# Extensions:
.NET Core + Visual Studio Code: criando rapidamente classes e interfaces com C# Extensions
Simplificando a manipulação de diferentes tipos de documentos que integram uma mesma coleção do MongoDB
Considerando a classe Produto:
E também a classe Servico:
Supondo que esses 2 tipos se referiram a documentos que estão em uma mesma coleção do MongoDB. Como podemos simplificar o desenvolvimento em ASP.NET Core, de forma a evitar a implementação de vários métodos com funcionalidades similares envolvendo os tipos Produto e Servico?
A resposta a esta pergunta passa pela utilização de Generics. Na próxima listagem temos a classe CatalogoContext, com a implementação do método genérico ObterItem para a consulta a documentos que integram um catálogo de produtos e serviços:
Na classe CatalogoController temos exemplos de utilização do tipo CatalogoContext:
O projeto utilizado como exemplo nesta seção está disponível no GitHub:
Protegendo APIs REST com JWT (JSON Web Tokens)
A adoção do padrão aberto conhecido como JSON Web Tokens (JWT) corresponde a uma das práticas mais difundidas visando o acesso seguro a APIs. Esta abordagem se vale de tokens criptografados para assim liberar a utilização de recursos de uma API, sendo que tal técnica recebeu o nome de Bearer Authentication.
No desenvolvimento de APIs REST em ASP.NET Core também se recomenda o uso de JWT, sendo que abordei esta prática em diversos artigos e posts agrupados no seguinte link:
ASP.NET Core + JWT: Guia de Referência
No Canal .NET a combinação ASP.NET Core + JWT também foi tema de uma live, em que foram cobertos de aspectos básicos a avançados da utilização de tokens em APIs REST. A gravação está disponível no YouTube:
Deixo ainda aqui diversos exemplos de projetos baseados em ASP.NET Core 2.2 e .NET Core 2.2 a implementação e consumo de APIs protegidas por JWT:
ASP.NET Core 2.2 + JWT (JSON Web Token) + Identity Core + Entity Framework Core InMemory + CORS
Implementando relacionamentos um-para-um em Dapper
Já abordei há algum tempo em um artigo como implementar relacionamentos um-para-um em Dapper:
Dapper: relacionamentos Um-para-Um e Um-para-Muitos (exemplos em ASP.NET Core)
Supondo as classes Estado e Regiao:
E uma API REST na qual o package Dapper foi previamente adicionado, teríamos um código similar ao seguinte para a configuração do relacionamento um-para-um:
- O método Query do Dapper possui com uma sobrecarga na qual devem ser especificadas as diferentes classes empregadas na produção do resultado. O último tipo informado corresponde à classe dos objetos retornados (Estado, neste caso);
- O parâmetro map utiliza uma expressão lambda, a fim de mapear os diferentes tipos de objetos gerados e devolver via instrução return a instância principal (tipo Estado). Os parâmetros informados aqui seguem a mesma ordem do método Query, com a referência indicada pelo parâmetro regiao sendo associada à propriedade DadosRegiao do objeto estado;
- No parâmetro splitOn estão os campos-chave dos objetos a serem gerados. Esta informação serve de base para que o Dapper efetue a separação dos dados em suas instâncias equivalentes
Na próxima imagem temos o resultado da execução desta API:
O código desta API REST de exemplo também está no GitHub:
Implementando relacionamentos um-para-muitos em Dapper
No mesmo artigo mencionado na seção anterior também descrevi como implementar relacionamentos um-para-muitos em Dapper:
Dapper: relacionamentos Um-para-Um e Um-para-Muitos (exemplos em ASP.NET Core)
Além do package Dapper, precisaremos desta vez incluir no projeto um pacote chamado Slapper.Automapper.
Neste novo exemplo utilizaremos outra variação das classes Regiao e Estado (uma região conterá uma lista de estados):
No Controller de uma API REST que retorna regiões e seus respectivos estados seria utilizada a classe AutoMapper (pertencente ao package Slapper.Automapper):
- A instrução AutoMapper.Configuration.AddIdentifier define o Id de cada tabela envolvida;
- A chamada a AutoMapper.MapDynamic permitirá a conversão do resultado levando em conta o relacionamento um-para-muitos, tudo isto com a execução de uma única query no banco de dados.
Como resultado de testes com esta API teríamos:
O código correspondente a esse projeto de exemplo também está no GitHub:
ASP.NET Core 2.2 + Dapper + Slapper.AutoMapper + SQL Server + One-to-Many
