Construire un Clone Postman avec Tim Corey

Aperçu du cours et objectif

Tim commence par expliquer que cette leçon concerne la mise en place de la structure initiale nécessaire pour construire un clone de Postman. Il déclare clairement que l'accent n'est pas encore mis sur la création de requêtes API ou le traitement des réponses JSON, mais plutôt sur la création des projets, leur configuration correcte, et la préparation de tout pour fonctionner.

Il explique que ce cours est conçu pour aider les utilisateurs à comprendre comment un outil réel comme Postman pourrait être construit en tant qu'application Windows simple. Bien que l'application finale ne remplacera pas Postman, elle démontrera des concepts de base tels que les requêtes REST, les réponses, et la conception d'interface utilisateur. Tim explique également que bien que ce projet puisse inspirer des travaux de portefeuille, les utilisateurs ne devraient pas le copier directement. À la place, ils devraient l'améliorer et le modifier pour créer quelque chose d'unique.

Créer la bibliothèque de classes pour le clone de Postman

À ce stade, Tim ouvre Visual Studio 2022 et commence le processus de configuration. Il explique qu'il utilise la dernière version disponible au moment de l'enregistrement et commence par créer un nouveau projet. Pour cette leçon, il choisit de créer d'abord la bibliothèque de classes.

Tim explique que cette bibliothèque de classes contiendra éventuellement du code partagé que l'UI référencera. Cette approche aide à séparer les préoccupations et à garder l'application organisée. Il explique aussi que même si l'ordre de création des projets n'a généralement pas d'importance, commencer par la bibliothèque lui permet de démontrer un problème courant que les développeurs peuvent rencontrer lors de la configuration.

Il cherche une bibliothèque de classes C# et insiste sur le fait qu'il doit s'agir d'un projet .NET moderne, pas de l'ancien .NET Framework. Tim sélectionne une bibliothèque de classes .NET 8, en remarquant que les versions plus récentes telles que .NET 9 ou ultérieures peuvent également fonctionner. Il explique que les différences entre les versions sont une partie normale du développement et que l'apprentissage de l'adaptation est une compétence importante.

Nommer la solution et les projets correctement

Tim passe du temps à expliquer comment il nomme la solution et les projets. Il nomme la solution comme l'application clone de Postman et la bibliothèque comme la bibliothèque clone de Postman. Il explique qu'inclure le mot "Library" rend très clair quel projet contient la logique partagée et lequel contient l'UI.

Cette approche de nommage aide lors du travail avec les références plus tard. Tim explique que les références devraient toujours circuler de l'UI à la bibliothèque, jamais dans l'autre sens. Ce choix de conception soutient un code plus propre et un meilleur processus de développement à long terme.

Il explique également pourquoi il ne place pas la solution et le projet dans le même répertoire. Puisque cette application contiendra plusieurs projets, les séparer facilite la navigation et évite les confusions à mesure que la solution se développe.

Ajouter le projet d'interface utilisateur Windows Forms

Une fois la bibliothèque créée, Tim ajoute un deuxième projet à la solution. Cette fois, il sélectionne une application Windows Forms. Il explique que ce projet servira d'interface utilisateur pour le clone de Postman et permettra finalement aux utilisateurs de saisir des URLs, des paramètres de requête, et d'afficher des réponses.

Il nomme le projet UI clone de Postman et confirme encore une fois qu'il utilise .NET 8. Tim aborde brièvement un message lié au DPI causé par la mise à l'échelle d'affichage. Il explique que ce n'est pas important pour cette leçon et que la gestion du DPI peut être explorée plus tard si nécessaire.

À ce stade, la solution contient maintenant deux projets : une bibliothèque et un UI Windows Forms. Cette structure pose les bases pour construire un outil de style Postman sur Windows.

Corriger le problème de projet de démarrage

Tim démontre un problème qui survient parce que la bibliothèque de classes a été créée en premier. Lorsqu'il essaie d'exécuter la solution, Visual Studio affiche une erreur indiquant qu'une bibliothèque de classes ne peut être démarrée directement.

Tim explique que c'est un problème courant de configuration et souligne l'importance de lire attentivement les messages d'erreur. Il explique que les messages d'erreur vous disent souvent exactement ce qui ne va pas et comment le réparer.

Il montre deux manières de résoudre le problème : définir le projet UI comme projet de démarrage en utilisant le menu contextuel, ou le sélectionner dans le menu déroulant de projet de démarrage près du bouton Exécuter. Une fois cela fait, l'UI Windows Forms se lance correctement.

Ajouter le projet à Git et GitHub

Avec la structure de solution en place, Tim passe au contrôle de source. Il ouvre la fenêtre Git Changes et explique que le contrôle de version n'a pas encore été activé. Il crée un dépôt Git directement depuis Visual Studio.

Tim explique l'objectif du fichier .gitignore, affirmant que les résultats de la construction, tels que les fichiers compilés, ne doivent pas être inclus dans le contrôle de source. Étant donné que ces fichiers peuvent être recréés, ils n'appartiennent pas à un dépôt GitHub.

Il discute également des licences et explique que choisir aucune licence signifie conserver tous les droits sur le code. Tim ajoute un fichier README et explique à quel point il est important pour expliquer le projet, surtout s'il sera partagé ou utilisé comme partie d'un portefeuille.

Tim nomme le dépôt GitHub, ajoute une description claire expliquant qu'il s'agit d'une recréation Windows Forms de Postman, et choisit de garder le dépôt privé afin que les utilisateurs se concentrent sur l'apprentissage plutôt que sur la copie de code.

Comprendre les indicateurs de contrôle de source

Après avoir poussé le code sur GitHub, Tim explique les icônes de verrouillage affichées dans l'Explorateur de Solutions. Ces icônes indiquent que les fichiers sont suivis par le contrôle de source et n'ont pas été modifiés.

Il explique comment ces indicateurs changent lorsque des fichiers sont ajoutés ou mis à jour, aidant les développeurs à comprendre quels changements seront engagés. Ce retour visuel devient très utile à mesure que le projet grandit et que plus de fonctionnalités sont ajoutées.

Garder Class1 et ajouter une référence

Tim explique pourquoi le fichier Class1 par défaut est laissé dans la bibliothèque pour l'instant. Sans au moins une classe, la bibliothèque n'aurait pas de namespace, rendant impossible sa référence depuis l'UI.

Il ajoute ensuite la bibliothèque en tant que dépendance du projet UI. Tim démontre à la fois le glisser-déposer de la bibliothèque sur les dépendances de l'UI et l'utilisation de l'option Ajouter une Référence de Projet. Cette étape permet à l'UI d'accéder au code partagé, essentiel pour construire un clone structuré de Postman.

Renommer Form1 en Dashboard

Tim renomme le Form1 par défaut en Dashboard, expliquant que ce formulaire représente l'écran principal de l'application. Lorsque ce formulaire se ferme, l'application se ferme également.

Il s'assure que toutes les références sont mises à jour correctement, y compris le fichier code-behind et Program.cs. Tim convertit également le namespace dans Program.cs en un namespace à portée de fichier, expliquant que cela offre plus d'espace et un formatage plus propre pour les futures modifications.

Ajuster les propriétés de l'UI et les paramètres de police

Tim ouvre le formulaire Dashboard et se concentre sur la fenêtre des Propriétés. Il explique comment les développeurs peuvent repositionner les fenêtres à l'intérieur de Visual Studio pour correspondre à leur flux de travail.

Il change le titre du formulaire pour identifier clairement l'application comme un clone de Postman et augmente la taille de la police par défaut de 9 à 18. Tim explique que définir la taille de la police tôt assure un dimensionnement cohérent pour tous les futurs contrôles ajoutés à l'UI.

Engager la configuration initiale

Avec tous les changements de configuration terminés, Tim met en scène les fichiers modifiés et crée un engagement. Il explique que le message d'engagement n'a pas besoin d'être parfait mais devrait décrire clairement les changements de configuration.

Il valide et synchronise le code avec GitHub, s'assurant que le repo est entièrement mis à jour et prêt pour le développement continu.

Préparation de l'étape suivante de construction du clone de Postman

Pour conclure la vidéo, Tim explique que la configuration du projet est maintenant terminée. Dans la prochaine leçon, l'accent sera mis sur la construction de l'interface utilisateur et la création d'un moyen simple d'envoyer des requêtes GET à une API et d'afficher les réponses.

Il encourage les spectateurs à tenter l'étape suivante par eux-mêmes avant de regarder la vidéo suivante. Le but est de créer une interface simple qui peut envoyer des requêtes, recevoir des données et afficher des réponses JSON formatées. Cette approche aide les utilisateurs à mieux comprendre le processus et les prépare à améliorer l'application au fil du temps.

Tim finit en rappelant aux spectateurs que ce projet est destiné à évoluer. Commencer par une configuration simple permet aux développeurs de prendre confiance, de comprendre le flux de travail et de transformer progressivement le projet en un outil de type Postman significatif.