API REST com MongoDB e .NET Core
•Transferir como PPTX, PDF•
0 gostou•67 visualizações
Mini curso ministrado na escola de férias da PUC MG para construção de uma API REST em .net core utilizando MongoDB
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (11)
Semelhante a API REST com MongoDB e .NET Core
Semelhante a API REST com MongoDB e .NET Core (20)
API REST com MongoDB e .NET Core
- 1. Banco de Dados NoSQL com .Net Core Bruno Gouvêa Roldão
- 2. Agenda 1. Net Core 2. API REST 3. Hands On – Criando uma API REST 4. Modelagem de domínios 5. Hands On – Criação de domínio 6. Banco de Dados Não Relacional 7. Hands On – Conectando nossa API ao MongoDB1. Basico do TDD
- 3. Introdução ao .Net Core
- 4. Detalhes • Sucessor do .Net Framework; • Open Source; • Multiplataforma; • 100% feito para se programar utilizando linha de comando;
- 5. Net Core
- 6. API REST
- 7. O que é uma API REST? • Servidor web; • Utiliza requisições HTTP para extrair, inserir, atualizar e deletar dados; • Permite a comunicação entre dois ou mais softwares distintos;
- 8. Porque utilizar? • Padrão adotado por toda a industria de tecnologia; • Utiliza o padrão HTTP; • Pode utilizar os principais tipos de formatos de arquivos para troca de informações, como o JSON e XML;
- 9. Verbos HTTP • GET • POST • PUT • DELETE
- 10. JSON • Formato de arquivo para troca de informações mais utilizado atualmente; • Simples; • Performático; • Leve.
- 11. Melhores Práticas – KISS • Semântica intuitiva; • Termos comuns e concretos (pedido, endereço, produto); • Não se deve ter mais de uma maneira de obter os mesmos dados;
- 12. Melhores Práticas – Métodos • Utilizar os verbos HTTP de maneira intuitiva; GET /EncontrarUsuario/1 GET /Usuario/1 POST /SalvarContatoUsuario POST /Usuario/1/Contato
- 13. HANDS ON Criando um WebApi em .Net Core
- 15. O que é DDD ? • Domain Driven Design; • Não é tecnologia; • Requer entendimento do negócio; • Não deve levar banco de dados em consideração; • Pode ser representado por meio de diagramas de classe do padrão UML.
- 16. Exemplo • Quero um software para restaurantes, • que me permita através de uma comanda eletrônica, • marcar a mesa do cliente, • que permita ao atendente fazer pedidos, • que o valor desta comanda seja calculada automaticamente, • e que seja possível efetuar pagamentos parciais ou totais
- 17. Exemplo • Quero um software para restaurantes, • que me permita através de uma comanda eletrônica, • marcar a mesa do cliente, • que permita ao atendente fazer pedidos, • que controle a quantidade de produtos consumidos, • e que calcule o valor e seja possível efetuar pagamentos parciais ou totais
- 18. Exemplo
- 20. HANDS ON Criando o domínio modelado e incrementando a API
- 21. Banco de dados não relacional
- 22. O que é um banco de dados? • Coleção de dados; • Representa informações sobre um domínio específico; • Possibilita recuperação e manipulação destes dados.
- 23. Conceitos de NoSQL • Not Only SQL; • Dados semi-estruturados (Schemas dinâmicos); • Maior controle da aplicação sobre os dados; • Relacionamentos “Embedded”.
- 25. MongoDB • Document Database; • Coleções e documentos ao invés de tabelas e registros; • Open Source. • Document Database; • Coleções e documentos ao invés de tabelas e registros; • Open Source. • Document Database; • Coleções e documentos ao invés de tabelas e registros; • Open Source. • Document Database; • Coleções e documentos ao invés de tabelas e registros; • Open Source.
- 26. Como são salvos os dados?
- 27. Vantagens • Fácil de escalar; • Trabalha melhor com sistemas distribuidos (microsserviços); • Desempenho; • Se adapta à modelagem da sua aplicação; • Não gera deadlock o/
- 28. Desvantagens • Exige mais espaço de armazenamento (HD); • Ferramentas de gerenciamento imaturas; • Desempenho;
- 29. HANDS ON Conectando nossa API ao MongoDB
- 30. Dúvidas?
- 31. Obrigado! Email: Brunogrbhg@gmail.com Facebook: /bruno.roldao Github: /Brunogr Linkedin: Bruno Gouvêa Roldão
Notas do Editor
- Contar história da minha experiência com TDD. Vou contar um pouco sobre a minha experiência com TDD. No primeiro projeto que utilizei essa técnica, eu não tinha um prazo bom, sendo apenas um mês para entregar uma solução, não tinha especificação do negócio e não dominava a técnica, conhecia vagamente o conceito, e já havia realizados testes de unidade anteriormente, mas nunca praticando o TDD. Durante o desenvolvimento, tive que ir me familiarizando com o TDD e compreendendo melhor como funcionava, me educando a utilizar e aos poucos fui conseguindo desenvolver técnicas e códigos auxiliares que me permitiam ter agilidade em desenvolver utilizando TDD. O mais interessante dessa experiência foi a forma como eu passei a compreender o modelo de negócios, que até então eu tinha dominio quase nulo. Programar utilizando TDD me fez compreender muito mais o negócio e ver aquilo do ponto de vista do usuário. Outra coisa interessante foi que eu pude ter um foco maior na arquitetura do software em si, sem me preocupar com banco de dados, de forma que até a última semana de desenvolvimento nós ainda não tinhamos banco de dados pronto, ele foi criado nessa última semana, quando o domínio da solução já estava bem modelado e as regras de negócio estavam todas implementadas.
- Contar história da minha experiência com TDD. Vou contar um pouco sobre a minha experiência com TDD. No primeiro projeto que utilizei essa técnica, eu não tinha um prazo bom, sendo apenas um mês para entregar uma solução, não tinha especificação do negócio e não dominava a técnica, conhecia vagamente o conceito, e já havia realizados testes de unidade anteriormente, mas nunca praticando o TDD. Durante o desenvolvimento, tive que ir me familiarizando com o TDD e compreendendo melhor como funcionava, me educando a utilizar e aos poucos fui conseguindo desenvolver técnicas e códigos auxiliares que me permitiam ter agilidade em desenvolver utilizando TDD. O mais interessante dessa experiência foi a forma como eu passei a compreender o modelo de negócios, que até então eu tinha dominio quase nulo. Programar utilizando TDD me fez compreender muito mais o negócio e ver aquilo do ponto de vista do usuário. Outra coisa interessante foi que eu pude ter um foco maior na arquitetura do software em si, sem me preocupar com banco de dados, de forma que até a última semana de desenvolvimento nós ainda não tinhamos banco de dados pronto, ele foi criado nessa última semana, quando o domínio da solução já estava bem modelado e as regras de negócio estavam todas implementadas.
- Como muitos já devem saber, o Test Driven Development é uma técnica que se baseia em um ciclo curto de repetições: - Criação do teste automatizado de uma nova funcionalidade, teste este que deve falhar; - Implementação minima do método a ser testado, possibilitando ao teste passer; - Por fim, refatoração do método para incluir regras de negócio mais complexas, garantindo a partir dali que aquele teste sempre irá passar.
- Como muitos já devem saber, o Test Driven Development é uma técnica que se baseia em um ciclo curto de repetições: - Criação do teste automatizado de uma nova funcionalidade, teste este que deve falhar; - Implementação minima do método a ser testado, possibilitando ao teste passer; - Por fim, refatoração do método para incluir regras de negócio mais complexas, garantindo a partir dali que aquele teste sempre irá passar.
- Contar história da minha experiência com TDD. Vou contar um pouco sobre a minha experiência com TDD. No primeiro projeto que utilizei essa técnica, eu não tinha um prazo bom, sendo apenas um mês para entregar uma solução, não tinha especificação do negócio e não dominava a técnica, conhecia vagamente o conceito, e já havia realizados testes de unidade anteriormente, mas nunca praticando o TDD. Durante o desenvolvimento, tive que ir me familiarizando com o TDD e compreendendo melhor como funcionava, me educando a utilizar e aos poucos fui conseguindo desenvolver técnicas e códigos auxiliares que me permitiam ter agilidade em desenvolver utilizando TDD. O mais interessante dessa experiência foi a forma como eu passei a compreender o modelo de negócios, que até então eu tinha dominio quase nulo. Programar utilizando TDD me fez compreender muito mais o negócio e ver aquilo do ponto de vista do usuário. Outra coisa interessante foi que eu pude ter um foco maior na arquitetura do software em si, sem me preocupar com banco de dados, de forma que até a última semana de desenvolvimento nós ainda não tinhamos banco de dados pronto, ele foi criado nessa última semana, quando o domínio da solução já estava bem modelado e as regras de negócio estavam todas implementadas.
- Como muitos já devem saber, o Test Driven Development é uma técnica que se baseia em um ciclo curto de repetições: - Criação do teste automatizado de uma nova funcionalidade, teste este que deve falhar; - Implementação minima do método a ser testado, possibilitando ao teste passer; - Por fim, refatoração do método para incluir regras de negócio mais complexas, garantindo a partir dali que aquele teste sempre irá passar.
- Como muitos já devem saber, o Test Driven Development é uma técnica que se baseia em um ciclo curto de repetições: - Criação do teste automatizado de uma nova funcionalidade, teste este que deve falhar; - Implementação minima do método a ser testado, possibilitando ao teste passer; - Por fim, refatoração do método para incluir regras de negócio mais complexas, garantindo a partir dali que aquele teste sempre irá passar.
- Como muitos já devem saber, o Test Driven Development é uma técnica que se baseia em um ciclo curto de repetições: - Criação do teste automatizado de uma nova funcionalidade, teste este que deve falhar; - Implementação minima do método a ser testado, possibilitando ao teste passer; - Por fim, refatoração do método para incluir regras de negócio mais complexas, garantindo a partir dali que aquele teste sempre irá passar.
- Como muitos já devem saber, o Test Driven Development é uma técnica que se baseia em um ciclo curto de repetições: - Criação do teste automatizado de uma nova funcionalidade, teste este que deve falhar; - Implementação minima do método a ser testado, possibilitando ao teste passer; - Por fim, refatoração do método para incluir regras de negócio mais complexas, garantindo a partir dali que aquele teste sempre irá passar.
- Como muitos já devem saber, o Test Driven Development é uma técnica que se baseia em um ciclo curto de repetições: - Criação do teste automatizado de uma nova funcionalidade, teste este que deve falhar; - Implementação minima do método a ser testado, possibilitando ao teste passer; - Por fim, refatoração do método para incluir regras de negócio mais complexas, garantindo a partir dali que aquele teste sempre irá passar.
- Como muitos já devem saber, o Test Driven Development é uma técnica que se baseia em um ciclo curto de repetições: - Criação do teste automatizado de uma nova funcionalidade, teste este que deve falhar; - Implementação minima do método a ser testado, possibilitando ao teste passer; - Por fim, refatoração do método para incluir regras de negócio mais complexas, garantindo a partir dali que aquele teste sempre irá passar.
- Contar história da minha experiência com TDD. Vou contar um pouco sobre a minha experiência com TDD. No primeiro projeto que utilizei essa técnica, eu não tinha um prazo bom, sendo apenas um mês para entregar uma solução, não tinha especificação do negócio e não dominava a técnica, conhecia vagamente o conceito, e já havia realizados testes de unidade anteriormente, mas nunca praticando o TDD. Durante o desenvolvimento, tive que ir me familiarizando com o TDD e compreendendo melhor como funcionava, me educando a utilizar e aos poucos fui conseguindo desenvolver técnicas e códigos auxiliares que me permitiam ter agilidade em desenvolver utilizando TDD. O mais interessante dessa experiência foi a forma como eu passei a compreender o modelo de negócios, que até então eu tinha dominio quase nulo. Programar utilizando TDD me fez compreender muito mais o negócio e ver aquilo do ponto de vista do usuário. Outra coisa interessante foi que eu pude ter um foco maior na arquitetura do software em si, sem me preocupar com banco de dados, de forma que até a última semana de desenvolvimento nós ainda não tinhamos banco de dados pronto, ele foi criado nessa última semana, quando o domínio da solução já estava bem modelado e as regras de negócio estavam todas implementadas.
- Como muitos já devem saber, o Test Driven Development é uma técnica que se baseia em um ciclo curto de repetições: - Criação do teste automatizado de uma nova funcionalidade, teste este que deve falhar; - Implementação minima do método a ser testado, possibilitando ao teste passer; - Por fim, refatoração do método para incluir regras de negócio mais complexas, garantindo a partir dali que aquele teste sempre irá passar.
- Como muitos já devem saber, o Test Driven Development é uma técnica que se baseia em um ciclo curto de repetições: - Criação do teste automatizado de uma nova funcionalidade, teste este que deve falhar; - Implementação minima do método a ser testado, possibilitando ao teste passer; - Por fim, refatoração do método para incluir regras de negócio mais complexas, garantindo a partir dali que aquele teste sempre irá passar.
- Como muitos já devem saber, o Test Driven Development é uma técnica que se baseia em um ciclo curto de repetições: - Criação do teste automatizado de uma nova funcionalidade, teste este que deve falhar; - Implementação minima do método a ser testado, possibilitando ao teste passer; - Por fim, refatoração do método para incluir regras de negócio mais complexas, garantindo a partir dali que aquele teste sempre irá passar.
- Como muitos já devem saber, o Test Driven Development é uma técnica que se baseia em um ciclo curto de repetições: - Criação do teste automatizado de uma nova funcionalidade, teste este que deve falhar; - Implementação minima do método a ser testado, possibilitando ao teste passer; - Por fim, refatoração do método para incluir regras de negócio mais complexas, garantindo a partir dali que aquele teste sempre irá passar.
- Antes de explicar a solução para o problema anterior, precisamos falar sobre injeção de dependência. Injeção de dependência tem como objetivo diminuir o acoplamento e facilitar o reuso. Consiste em você fazer uma inversão de controles; ao invés de você instanciar uma classe, você passa essa responsabilidade para um builder que fará isso por você. Dessa forma, programamos para interfaces, garantindo que uma classe não é afetada pela outra quando há modificações. É simplesmente impossível utilizar TDD sem implementar injeção de dependência no seu projeto, o que faz dele um pré requisito
- Contar história da minha experiência com TDD. Vou contar um pouco sobre a minha experiência com TDD. No primeiro projeto que utilizei essa técnica, eu não tinha um prazo bom, sendo apenas um mês para entregar uma solução, não tinha especificação do negócio e não dominava a técnica, conhecia vagamente o conceito, e já havia realizados testes de unidade anteriormente, mas nunca praticando o TDD. Durante o desenvolvimento, tive que ir me familiarizando com o TDD e compreendendo melhor como funcionava, me educando a utilizar e aos poucos fui conseguindo desenvolver técnicas e códigos auxiliares que me permitiam ter agilidade em desenvolver utilizando TDD. O mais interessante dessa experiência foi a forma como eu passei a compreender o modelo de negócios, que até então eu tinha dominio quase nulo. Programar utilizando TDD me fez compreender muito mais o negócio e ver aquilo do ponto de vista do usuário. Outra coisa interessante foi que eu pude ter um foco maior na arquitetura do software em si, sem me preocupar com banco de dados, de forma que até a última semana de desenvolvimento nós ainda não tinhamos banco de dados pronto, ele foi criado nessa última semana, quando o domínio da solução já estava bem modelado e as regras de negócio estavam todas implementadas.