Construa Clone do Postman com Tim Corey

Visão Geral do Curso e Propósito

Tim começa explicando que esta lição trata de configurar a estrutura inicial necessária para construir um clone do Postman. Ele declara claramente que o foco não é em fazer requisições de API ou lidar com respostas JSON ainda, mas sim criar os projetos, configurá-los corretamente e preparar tudo para funcionamento.

Ele explica que este curso é projetado para ajudar usuários a entenderem como uma ferramenta do mundo real como o Postman poderia ser construída como um aplicativo Windows simples. Embora o aplicativo final não vá substituir o Postman, ele demonstrará conceitos centrais como requisições REST, respostas e design de IU. Tim também explica que enquanto este projeto pode inspirar trabalho de portfólio, os usuários não devem copiá-lo diretamente. Em vez disso, eles devem aprimorá-lo e modificá-lo para criar algo exclusivamente deles.

Criando a Biblioteca de Classes para o Clone do Postman

Neste ponto, Tim abre o Visual Studio 2022 e inicia o processo de configuração. Ele explica que está usando a versão mais recente disponível no momento da gravação e começa criando um novo projeto. Para esta lição, ele escolhe criar a biblioteca de classes primeiro.

Tim explica que esta biblioteca de classes eventualmente conterá código compartilhado que a IU irá referenciar. Essa abordagem ajuda a separar preocupações e a manter o aplicativo organizado. Ele também explica que, embora a ordem de criação dos projetos geralmente não importe, começar pela biblioteca permite a ele demonstrar um problema comum que os desenvolvedores podem enfrentar durante a configuração.

Ele procura por uma biblioteca de classes em C# e enfatiza que deve ser um projeto .NET moderno, não o mais antigo .NET Framework. Tim seleciona uma biblioteca de classes .NET 8, observando que versões mais novas como .NET 9 ou posteriores também podem funcionar. Ele explica que diferenças entre versões são uma parte normal do desenvolvimento e que aprender a se adaptar é uma habilidade importante.

Nomeando Soluções e Projetos Corretamente

Tim passa algum tempo explicando como ele nomeia a solução e os projetos. Ele chama a solução de aplicativo clone do Postman e a biblioteca de biblioteca clone do Postman. Ele explica que incluir a palavra "Biblioteca" deixa muito claro qual projeto contém a lógica compartilhada e qual projeto contém a IU.

Esta abordagem de nomenclatura ajuda ao trabalhar com referências mais tarde. Tim explica que as referências devem sempre fluir da IU para a biblioteca, nunca ao contrário. Esta escolha de design apoia um código mais limpo e um melhor processo de desenvolvimento a longo prazo.

Ele também explica por que não coloca a solução e o projeto no mesmo diretório. Uma vez que este aplicativo conterá vários projetos, separá-los facilita a navegação e evita confusão à medida que a solução cresce.

Adicionando o Projeto de IU do Windows Forms

Uma vez que a biblioteca é criada, Tim adiciona um segundo projeto à solução. Desta vez, ele seleciona um aplicativo Windows Forms. Ele explica que este projeto servirá como a IU para o clone do Postman e eventualmente permitirá que os usuários inseram URLs, parâmetros de consulta e vejam as respostas.

Ele nomeia o projeto de IU clone do Postman e novamente confirma que está usando .NET 8. Tim aborda brevemente uma mensagem relacionada a DPI causada pela escala de exibição. Ele explica que isso não é importante para esta lição e que o manuseio de DPI pode ser explorado mais tarde, se necessário.

Neste estágio, a solução agora contém dois projetos: uma biblioteca e uma interface de Windows Forms. Esta estrutura estabelece a base para construir uma ferramenta no estilo Postman no Windows.

Corrigindo o Problema do Projeto de Inicialização

Tim demonstra um problema que ocorre porque a biblioteca de classes foi criada primeiro. Quando ele tenta executar a solução, o Visual Studio mostra um erro indicando que uma biblioteca de classes não pode ser iniciada diretamente.

Tim explica que este é um problema comum de configuração e enfatiza a importância de ler atentamente as mensagens de erro. Ele explica que as mensagens de erro frequentemente dizem exatamente o que está errado e como corrigi-lo.

Ele mostra duas maneiras de resolver o problema: definindo o projeto da interface como o projeto de inicialização usando o menu de contexto ou selecionando-o no menu suspenso do projeto de inicialização perto do botão Executar. Depois disso, a interface de Windows Forms é iniciada corretamente.

Adicionando o Projeto ao Git e GitHub

Com a estrutura da solução em vigor, Tim passa para o controle de versão. Ele abre a janela de Alterações do Git e explica que o controle de versão ainda não foi habilitado. Ele cria um repositório Git diretamente do Visual Studio.

Tim explica o propósito do arquivo .gitignore, afirmando que saídas de compilação, como arquivos compilados, não devem ser incluídas no controle de versão. Como esses arquivos podem ser recriados, eles não pertencem a um repositório do GitHub.

Ele também discute licenciamento e explica que escolher sem licença significa reter todos os direitos sobre o código. Tim adiciona um arquivo README e explica como é importante explicar o projeto, especialmente se ele for compartilhado ou usado como parte de um portfólio.

Tim nomeia o repositório do GitHub, adiciona uma descrição clara explicando que este é uma recriação do Postman em Windows Forms e escolhe manter o repositório privado para que os usuários se concentrem em aprender em vez de copiar código.

Entendendo Indicadores de Controle de Versão

Após enviar o código para o GitHub, Tim explica os ícones de cadeado mostrados no Solution Explorer. Esses ícones indicam que os arquivos são rastreados pelo controle de versão e não foram modificados.

Ele explica como esses indicadores mudam quando arquivos são adicionados ou atualizados, ajudando os desenvolvedores a entender quais alterações serão confirmadas. Este feedback visual torna-se muito útil à medida que o projeto cresce e mais recursos são adicionados.

Manter o Class1 e Adicionar uma Referência

Tim explica por que o arquivo padrão Class1 é deixado na biblioteca por enquanto. Sem pelo menos uma classe, a biblioteca não teria um namespace, tornando impossível a referência a partir da interface.

Ele então adiciona a biblioteca como uma dependência do projeto da interface. Tim demonstra tanto arrastando a biblioteca para as dependências da interface quanto usando a opção Adicionar Referência de Projeto. Esta etapa permite que a interface acesse o código compartilhado, que é essencial para construir um clone estruturado do Postman.

Renomeando o Form1 para Dashboard

Tim renomeia o Form1 padrão para Dashboard, explicando que este formulário representa a tela principal da aplicação. Quando este formulário é fechado, a aplicação também é fechada.

Ele garante que todas as referências sejam atualizadas corretamente, incluindo o arquivo code-behind e Program.cs. Tim também converte o namespace em Program.cs para um namespace delimitado por arquivo, explicando que isso oferece mais espaço e formatação mais limpa para futuras mudanças.

Ajustando Propriedades da Interface e Configurações de Fonte

Tim abre o formulário do Dashboard e foca na janela Propriedades. Ele explica como os desenvolvedores podem reposicionar janelas dentro do Visual Studio para corresponder ao seu fluxo de trabalho.

Ele muda o título do formulário para identificar claramente o aplicativo como um clone do Postman e aumenta o tamanho da fonte padrão de 9 para 18. Tim explica que definir o tamanho da fonte desde cedo garante um dimensionamento consistente para todos os controles futuros adicionados à interface.

Commitando a Configuração Inicial

Com todas as alterações de configuração concluídas, Tim prepara os arquivos modificados e cria um commit. Ele explica que a mensagem de commit não precisa ser perfeita, mas deve descrever claramente as alterações de configuração.

Ele faz o commit e sincroniza o código com o GitHub, garantindo que o repositório esteja totalmente atualizado e pronto para desenvolvimento contínuo.

Preparando-se para o Próximo Passo na Construção do Clone do Postman

Para encerrar o vídeo, Tim explica que a configuração do projeto está agora completa. Na próxima lição, o foco mudará para construir a interface e criar uma maneira simples de enviar solicitações GET para uma API e exibir respostas.

Ele encoraja os espectadores a tentarem o próximo passo por conta própria antes de assistirem ao próximo vídeo. O objetivo é criar uma interface simples que possa enviar solicitações, receber dados e exibir respostas JSON formatadas. Esta abordagem ajuda os usuários a entender melhor o processo e os prepara para aprimorar o aplicativo ao longo do tempo.

Tim encerra lembrando os espectadores que este projeto é destinado a crescer. Começar com uma configuração simples permite que os desenvolvedores ganhem confiança, entendam o fluxo de trabalho e transformem gradualmente o projeto em uma ferramenta significativa no estilo Postman.