‫Instructeur : Jusqu'à
‫présent, nous avons juste écrit notre code sans
‫trop penser à l'architecture de notre application.
‫Ce n'était pas vraiment important jusqu'à présent, mais
‫maintenant que notre application commence vraiment à se développer, nous devons
‫commencer à nous
‫inquiéter de la façon dont nous concevons ou de l'architecture du code.
‫Et cette conférence ne sera qu'une brève
‫introduction à l'architecture back-end.
‫A commencer par l'architecture MVC.
‫Ainsi, dans ce projet,
‫nous allons utiliser une architecture largement
‫utilisée et bien connue appelée modèle, vue,
‫contrôleur ou MVC en abrégé.
‫Et il
‫existe différentes manières d'implémenter l'architecture MVC, certaines
‫plus complexes que d'autres,
‫mais nous allons
‫l'implémenter ici de manière très simple.
‫Je voulais juste vous
‫faire savoir que si vous recherchez
‫MVC, vous le trouverez implémenté de différentes manières.
‫Bon, de toute façon, dans cette architecture, la
‫couche modèle s'occupe de tout
‫ce qui concerne les données des applications et
‫la logique métier.
‫Et nous allons apprendre ce que la logique métier signifie
‫dans la diapositive suivante.
‫Ensuite, nous avons la couche de contrôleur
‫et la fonction des contrôleurs
‫est de gérer la demande de l'application,
‫d'interagir avec les
‫modèles et de renvoyer les réponses au client.
‫Et tout cela s'appelle la logique d'application.
‫Enfin, la couche de vue est nécessaire
‫si nous avons une interface graphique dans notre application.
‫Ou en d'autres termes, si nous
‫construisons un site Web rendu côté serveur, comme
‫nous en avons déjà parlé.
‫Dans ce cas, la couche de vue se
‫compose essentiellement des modèles utilisés pour
‫générer la vue, donc le site Web que nous allons renvoyer au client.
‫Et c'est la logique de présentation.
‫Pour l'instant, nous ne faisons que construire une API,
‫donc nous ne sommes pas encore vraiment préoccupés par les vues.
‫C'est pour un peu plus tard dans le cours.
‫Ainsi, l'utilisation d'un modèle ou d'une architecture comme celle-ci nous
‫permet d'écrire une application plus modulaire, qui
‫sera beaucoup plus facile à maintenir à
‫l'échelle, si nécessaire.
‫Et nous pourrions aller encore
‫plus loin et ajouter ici plus de couches d'abstraction.
‫Mais dans ce genre d'application plus
‫petite, l'architecture MVC est plus que suffisante pour nos besoins.
‫Maintenant, tout cela peut
‫sembler un peu abstrait, alors examinons MVC dans le contexte
‫de notre application et le cycle requête-réponse.
‫Comme toujours, tout commence par une demande.
‫Cette demande touchera l'un de nos routeurs, car
‫rappelez-vous que nous avons plusieurs routeurs.
‫Fondamentalement, un pour chaque
‫ressource, comme les visites, les utilisateurs, etc.
‫Maintenant, le but du routeur est de déléguer la
‫requête à la fonction
‫de gestionnaire appropriée, qui sera dans l'un des contrôleurs.
‫Et encore une fois, il y
‫aura un contrôleur pour chacune
‫de nos ressources, pour garder ces différentes parties de l'application bien séparées.
‫Ensuite, en fonction de la demande entrante, le
‫contrôleur peut avoir besoin d'interagir avec l'un
‫des modèles, par exemple pour
‫récupérer un certain
‫document de la base de données
‫ou pour en créer un nouveau.
‫Une fois de plus, il existe un fichier modèle pour chaque ressource.
‫Après avoir obtenu les données
‫du modèle, le contrôleur peut alors être prêt à
‫renvoyer une réponse au client, par exemple, contenant ces données.
‫Maintenant, au cas où nous voudrions réellement restituer un site
‫Web, il reste une étape supplémentaire.
‫Dans ce cas, après avoir récupéré les données du
‫modèle, le contrôleur sélectionnera
‫alors l'un des modèles de vue et y injectera les données.
‫Ce site Web rendu sera ensuite renvoyé
‫en tant que réponse.
‫Dans la couche de vue d'une application
‫Express, il existe généralement un modèle de vue pour chaque page.
‫Comme une page de présentation d'une
‫visite, une page de détails de visite ou une page de connexion.
‫Dans l'exemple de notre dernière application bien sûr.
‫Voilà donc une vue d'ensemble de l'architecture que nous
‫allons implémenter dans ce projet.
‫Maintenant, pour finir, permettez-moi d'entrer un
‫peu plus dans les détails sur le modèle et le contrôleur.
‫Ainsi, l'un des grands objectifs de MVC est
‫de séparer la logique
‫métier de la logique applicative.
‫Vous entendrez parler de ces types de logique tout
‫le temps lorsque vous parcourez
‫Stack Overflow ou un site comme celui-ci.
‫Mais quels sont ces types de logique en fait ?
‫Eh bien, la différence est un peu opiniâtre, mais
‫voici mon point de vue :
‫ainsi, la logique de l'application est tout le code
‫qui ne concerne que
‫l'implémentation de l'application et non
‫le problème commercial sous-jacent que
‫nous essayons réellement de résoudre avec l'application .
‫Comme montrer et vendre
‫des visites, gérer le stock d'un
‫supermarché ou organiser une bibliothèque, par exemple.
‫Encore une fois, la logique de
‫l'application est la logique qui fait que l'application fonctionne réellement.
‫Par exemple, une grande partie de la logique d'application dans
‫Express concerne la gestion des demandes et des réponses.
‫Donc, dans un sens, on
‫peut aussi dire que la logique d'application est plus technique.
‫De plus, si nous avons des vues dans notre
‫application, la logique de l'application
‫sert de pont entre les couches de modèle et de
‫vue afin que nous ne mélangeions jamais
‫la logique métier avec la logique de présentation.
‫D'accord?
‫Maintenant, à propos de la
‫logique métier, c'est tout le code qui résout réellement le problème
‫métier que nous avons décidé de résoudre.
‫Disons encore une fois que notre objectif est de montrer des visites aux clients
‫et de les vendre ensuite.
‫Et le code qui est directement lié aux règles métier,
‫au fonctionnement de l'entreprise
‫et aux besoins de l'entreprise est la logique métier.
‫Maintenant, si cela semble encore un peu trop philosophique, quelques
‫exemples dans le contexte de notre dernière application sont de
‫créer de nouvelles visites dans la base de données de l'application,
‫de vérifier si le mot de passe d'un utilisateur est correct lorsqu'il se connecte,
‫de valider les données d'entrée de l'utilisateur
‫ou de s'assurer que seuls les utilisateurs qui a acheté un certain
‫tour peut l'examiner.
‫Donc, tout cela concerne l'entreprise elle-même, et cela fait
‫donc partie de la logique commerciale.
‫Maintenant, nous devons garder
‫à l'esprit que la logique applicative et
‫la logique métier sont presque impossibles à séparer complètement,
‫et donc parfois elles se chevauchent.
‫Mais nous devons faire
‫de notre mieux pour conserver la logique applicative
‫dans nos contrôleurs et la logique métier dans nos modèles.
‫Et il y a même cette
‫philosophie des gros modèles, des contrôleurs
‫minces, qui dit que
‫nous devrions décharger autant de logique que possible dans
‫les modèles, pour garder les contrôleurs aussi simples et légers que possible.
‫Ainsi, un gros modèle aura autant de logique métier que
‫nous pouvons lui en décharger,
‫et un contrôleur léger aura aussi peu de logique que possible,
‫de sorte que le contrôleur
‫sert principalement à gérer les demandes et les réponses
‫de l'application.
‫D'accord?
‫Alors, maintenant, gardez tout cela à l'esprit pendant
‫que nous avançons et progressons dans la création de nos applications.