Baixar para ler offline
Carregado porBruno Roldão
Minicurso - Banco de Dados NoSQL com .Net Core
O documento aborda a criação de APIs REST com .NET Core, incluindo conceitos fundamentais como TDD, modelagem de domínio e bancos de dados NoSQL, especificamente MongoDB. Ele explora as melhores práticas e requisitos do DDD, além de oferecer hands-on em construção de APIs e conexão com o banco de dados. Vantagens e desvantagens do uso de bancos de dados não relacionais também são discutidas.
Minicurso - Banco de Dados NoSQL com .Net Core
- 1. Banco de DadosNoSQL 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.
- 4. Detalhes • Sucessor do.Net Framework; • Open Source; • Multiplataforma; • 100% feito para se programar utilizando linha de comando;
- 5.
- 6.
- 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ãoadotado 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 dearquivo 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 umWebApi em .Net Core
- 14.
- 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 umsoftware 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 umsoftware 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.
- 19.
- 20. HANDS ON Criando odomínio modelado e incrementando a API
- 21. Banco de dadosnã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”.
- 24.
- 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 salvosos dados?
- 27. Vantagens • Fácil deescalar; • Trabalha melhor com sistemas distribuidos (microsserviços); • Desempenho; • Se adapta à modelagem da sua aplicação; • Não gera deadlock o/
- 28. Desvantagens • Exige maisespaço de armazenamento (HD); • Ferramentas de gerenciamento imaturas; • Desempenho;
- 29. HANDS ON Conectando nossaAPI ao MongoDB
- 30.
- 31. Obrigado! Email: Brunogrbhg@gmail.com Facebook: /bruno.roldao Github:/Brunogr Linkedin: Bruno Gouvêa Roldão
Notas do Editor
- #3 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.
- #4 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.
- #5 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.
- #6 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.
- #7 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.
- #8 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.
- #9 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.
- #10 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.
- #11 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.
- #12 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.
- #13 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.
- #15 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.
- #16 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.
- #17 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.
- #18 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.
- #19 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.
- #20 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
- #22 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.