ASP.Net Core WebAPI e DAPPER - projeto final

em

Olá. Recentemente concluí meu pequeno projeto de estudo de ASP.NET CORE e DAPPER.

A ideia era aprender a usar estas duas ferramentas e acrescentar algo novo nos meus conhecimentos já que, por muito tempo tudo o que eu conhecia de Webservices era o clássico XML Webservice.

Assim, me propus a criar um mini serviço (não, ainda não é um micro service, sorry) com as operações CRUD básicas expostas através de um serviço do tipo Restful Web API. Quero contar aqui neste post um pouco da experiência e deixar alguns links de referência, se você tiver interesse pelo assunto.

Breve introdução aos Restful Web API's

Restful Web API's consistem em serviços baseados no protocolo HTTP. Sua principal característica está no uso das requisições GET, POST, PUT e DELETE e do formato JSON para envio e recepção dos dados. Este tipo de serviço pode ser considerado como uma evolução dos XML Webservices e também a base para a composição de micro serviços.

Usando um serviço construído baseado nessa metodologia é possível criar uma aplicação que permita realizar as quatro operações CRUD - Create, Read, Update e Delete - disponibilizada de forma bastante direta através das requisições HTTP.

Com o Restful além de termos a interoperabilidade permitida pelos protocolos HTTP possibilitando aplicações de diferentes plataformas consumirem os serviços, também se tem a robustez e menor consumo de banda de rede já que são usadas requisições HTTP.

Usando o ASP.NET CORE para o desenvolvimento deste tipo de serviço se tem uma ferramenta simples e robusta.

Simples porque para criar respostas às requisições GET, POST, PUT e DELETE são usados elementos conhecidos da linguagem C# (se você optar por esta - e provavelmente vai querer usar). Robusta porque, conforme o conhecimento dos recursos vai se aprofundando, mais funcionalidades podem ser adicionadas.

O mapeador ORM DAPPER

Fazer a tradução dos dados relacionais armazenados em bancos de dados como o SQL Server para o modelo ORM usado nas linguagens como o C# sempre foi um desafio. Já existem bons mapeadores como o Entity Framework - da própria Microsoft entre outros.

Porém, um dos pontos que é mais crítico é seu desempenho e facilidade de uso.

Com o DAPPER existe a promessa melhoria no desempenho como simplificação do código.

Este é um projeto open source do portal Stack Overflow criado para resolver os problemas que eles tinham com desempenho ao realizar consultas em bases de dados.

Seu uso é bem parecido com o ADO.NET já que é necessário criar as consultas e conexões manualmente. As consultas são escritas em SQL sem suporte ainda para o LINQ. No projeto achei interessante incluir este recurso para testar suas funcionalidades básicas.

Ao escrever o código não tive dificuldade alguma. No projeto as consultas são bem simples, usam apenas uma tabela e o nome das propriedades da classe é o mesmo das colunas da tabela.

Novos testes serão necessários para verificar se o desempenho é bom mesmo como para conhecer o comportamento do DAPPER em situações de consultas com várias tabelas, vários objetos aninhados e também com nome de propriedades diferentes do nome das colunas do banco de dados.

O projeto

Escolhi criar um projeto no GitHub primeiramente para começar a explorar a plataforma e seus recursos.

Também optei em criar um projeto bem simples - trata-se apenas de realizar as operações CRUD em uma tabela com o propósito de agendar compromissos - para não ter de implementar regras de negócio complexas.

Para isto, o projeto "AGENDA" como é o nome dado, consiste de serviços para consultar, incluir, atualizar e remover registros de compromissos em uma agenda.

O "dono" do compromisso é controlado pelo nome. Há uma data de início e outra de término. Deve ser informado um título e uma descrição para o compromisso e mais nada.

Não foram consideradas permissões de acesso ou quaisquer restrições.

Assim, o foco neste projeto estava em aprender os recursos e documentar o funcionamento básico destes.

Ferramentas usadas

A escolha de ferramentas se baseou principalmente nas limitações que eu tenho de máquina. Em casa uso um notebook Dell Inspiron bem antigo. Inicialmente não tenho planos de trocar já que no meu trabalho já tenho outro notebook potente.

Para o projeto trabalhei então com o Visual Studio 2017 Community Edition que é uma versão gratuita. Não percebi nada que impeça usar esta versão no dia a dia fora a lentidão.

Tentei usar o Visual Studio Code, porém, como a versão do meu Windows é de 32 bits e também não tenho planos e nem orçamento para fazer upgrade, fiquei sem a capacidade de fazer debug no projeto. Isso influenciou bastante para que eu usasse o Visual Studio.

Como banco de dados, escolhi o SQL Server 2014 EXPRESS. Mais uma vez as limitações de máquina forçaram a usar esta versão. Com as Express Editions, é possível usar bancos de dados com até 10GB. Se estiver interessado em um banco para desenvolvimento e estudos, certamente esta versão vai ajudar.

Por fim, foi necessário encontrar uma ferramenta que permitisse executar as requisições para os serviços da API. Isto foi feito de uma maneira bem competente pelo POSTMAN.

Com essa aplicação é possível fazer vários tipos de requisições HTTP. São exibidos os cabeçalhos e o conteúdo do fluxo de dados enviado. Também se visualiza o código Java Script para fazer isso o que vem a ser bem interessante para a construção de um front end.

Dificuldades encontradas e soluções

Durante o estudo foi difícil realizar algumas tarefas simples. A documentação não permitiu encontrar de maneira rápida itens simples como, por exemplo:

  • Recuperação da string de conexão.
  • Obter os parâmetros das requisições
  • Resolver problemas de métodos que não eram visualizados pelo POSTMAN

Tudo isso foi resolvido com bastante pesquisa, conversa de corredor na hora do café na empresa e velha e boa tentativa e erro.

Próximos passos

Espero que com este post e com o projeto, outras pessoas possam se sentir animadas a aprender esta ferramenta. Está tudo documentado e acredito ser um bom começo para entender como tudo vai funcionar.

Alguns pontos ficaram para estudos posteriores entre os quais:

  • Segurança dos métodos. Como está desenvolvido, qualquer programa que tiver acesso a URL dos serviços conseguirá consumir os dados. É importante, quando for desenvolver API's criar métodos de segurança como logins e tokens.
  • Armazenamento de objetos complexos com o DAPPER. Nos exemplos apenas um objeto plano ou seja, sem outros objetos conectados e outras tabelas foi usado. Em situações reais isso raramente acontece.
  • Documentação da API. É uma boa prática documentar os métodos disponibilizados quando são criados e publicados serviços para uso público.

Convido você a dar uma olhada no projeto que está no GITHUB. Até a próxima.

Links para artigos anteriores