Salut et bienvenue dans ce nouvel épisode du podcast de Code Garage,
je m'appelle Nicolas Brandin-Bernard et aujourd'hui on va essayer de comprendre
l'architecture MVC. Alors avant de commencer à parler justement de cette architecture,
je vous conseille d'aller écouter l'épisode 54 du podcast qui est dédié à l'architecture
logicielle dans son ensemble, si jamais ce n'est pas déjà fait parce que sinon vous risquez de
manquer un petit peu quelques notions théoriques on va dire assez au niveau. Alors je sais même
si le titre de cet épisode c'est comprendre l'architecture MVC, c'est important de noter que
quand on parle de MVC justement on doit plutôt parler de patrons de conception ou de design
paterne en anglais. Principalement parce que l'architecture de votre logiciel et bien il ne
s'arrête pas au fait de choisir un patron de conception, c'est plutôt un vast ensemble de choix
qui va influer sur l'architecture globale. Même si c'est vrai le modèle MVC, il guide beaucoup la
structure de votre code et donc ce n'est pas non plus une mauvaise chose d'utiliser ce terme là,
simplement on va essayer d'être encore un peu plus précis dans cet épisode. Alors maintenant
entrons dans le vif du sujet le modèle MVC. MVC ça signifie modèle vu contrôleur, c'est la même
chose en anglais puisque tous les mots sont quasiment transparents c'est modèle view controller.
C'est une approche de conception, patron de conception qui divise un logiciel ou une application
en trois composants principaux. Vous les aurez deviné évidemment le modèle la vue et le
contrôleur, ça je vous apprends rien, ça fait plusieurs fois qu'on le répète. D'abord concentrons
nous sur le modèle. Le modèle c'est là que les données sont stockées et manipulées. Si vous avez
une application météo par exemple, le modèle il va pouvoir contenir les informations sur la
température, la pression atmosphérique, les différentes informations sur l'utilisateur et sa
position géographique mais aussi la manière de traiter ses informations et la logique pour
gérer toutes ces informations. La vue elle de son côté c'est ce que voient les utilisateurs. Si on
reprend l'exemple de l'application météo, la vue sera l'interface utilisateur qui affiche
justement les prévisions, les graphiques, les images etc. Et enfin le contrôleur,
le contrôleur c'est un peu comme un chef d'orchestre. Il prend les commandes de l'utilisateur
depuis la vue comme par exemple affiche-moi la météo de telle ville et il va interagir
par exemple avec le modèle pour récupérer les données ou bien demander au modèle de les mettre
à jour ou d'en créer de nouvelles. Et puis ensuite il va renvoyer le résultat à la vue. Globalement
si on fait un petit topo, on se rend compte que la vue elle peut discuter avec le contrôleur,
elle connaît le contrôleur, le contrôleur la connaît. Le contrôleur lui il va discuter avec
le modèle, pareil il se connaît entre eux, mais jamais la vue et le modèle ne discuteront ensemble
parce qu'ils passeront forcément par un contrôleur. Alors si jamais on prend une analogie,
une analogie par exemple avec un restaurant pour rendre ça un petit peu plus concret,
eh bien comment est-ce que ça se passerait ? Le modèle ce serait votre cuisine où tous les
ingrédients sont stockés, préparés, ils sont cuit, ils sont mélangés ensemble,
d'une bonne ordre pour justement faire les recettes du restant. La vue, elle se serait la
salle à manger où eh bien vos clients ils voient, ils consomment vos plats, ils consultent le menu,
ils peuvent commander etc. Et le contrôleur c'est justement le serveur ou la serveuse qui
prend la commande du client dans la vue et qui communique avec la cuisine le modèle et qui apporte
finalement les plats à table. Donc le contrôleur le serveur au sens restaurant évidemment,
pas au sens informatique, eh bien il va se contenter de faire, de faciliter la communication entre
ces deux entités. Jamais vous allez avoir un serveur qui va décider de lui-même de créer une
nouvelle recette et de la mettre sur le menu. Non parce que si jamais il décide d'une recette
où en fait on n'a pas les ingrédients en cuisine, ça ne sert à rien et évidemment le client sera
mécontent. Bien là c'est exactement pareil, la cuisine va fournir une liste de menus, enfin une liste
plutôt de plats, le contrôleur lui va se, va se, se, être chargé d'apporter les menus et dans la
vue eh bien on va choisir, dans le, on va choisir un plat par mille menus et ensuite on va demander
au contrôleur d'aller l'envoyer justement dans le modèle donc en cuisine qui va ramener le plat
etc. etc. et toute la communication se fera comme ça. C'est le concept même de justement modèle
vue contrôleur, chaque composant a un rôle distinct mais il travaille tous ensemble pour
offrir une expérience utilisateur complète et justement qu'on se retrouve, qu'on s'y retrouve
dans le code. Alors c'est quoi exactement les avantages de l'architecture MVC ? Eh bien comme
tout patron de conception ou en tout cas comme globalement toute architecture eh bien ça nous
permet de séparer les préoccupations. En anglais on parle souvent de separations of concerns donc
justement c'est la séparation des préoccupations. En ICA et MVC, ça nous permet clairement de
séparer les responsabilités. Le modèle gère les données, la vue gère l'interface utilisateur et le
contrôleur gère la logique de l'application. Ça rend un code plus lisible et surtout plus
facile à entretenir. Ensuite ça permet également la réutilisation du code parce qu'en découpant
l'application en trois composants distincts eh bien ça devient plus facile de réutiliser le code.
Vous pouvez changer la vue sans toucher au modèle ou vice versa. Vous pouvez changer le modèle et
même changer par exemple de modèle de base de données, de service de base de données et
simplement il faudra adapter votre modèle mais ni le contrôleur ni la vue n'aura à changer.
Et évidemment quand en général on optimise la réutilisation du code eh bien ça facilite le
test aussi, enfin les tests parce que comme chaque composant peut être testé indépendamment et
puisqu'il est indépendant, vous allez pouvoir tester la logique du modèle sans vous soucier de
l'interface utilisateur, ce qui facilite grandement les tests unitaires par exemple. Alors pour finir
justement sur cette architecture ou ce patron de conception MVC, on va parler d'une bonne pratique
qu'on appelle en anglais thin controllers and fat models, donc en français les contrôleurs maigres
et les gros modèles. Eh bien c'est tout simplement le concept d'avoir le moins de code possible,
le moins de logique possible dans nos contrôleurs et de mettre un maximum, enfin en tout cas de
mettre toute la logique, un maximum de la logique dans les modèles. Donc ça veut dire que le
traitement des données, la gestion, la modification des données etc, même directement la communication
avec la base de données eh bien tout ça va se faire dans les modèles. Le contrôleur lui il va
simplement servir à faire la communication et éventuellement parfois eh bien de faire de la
gestion de droit, donc par exemple si un utilisateur a le droit ou pas d'accéder à telle partie des
données eh bien ça on va pouvoir le mettre cette logique là dans justement les contrôleurs. Mais
c'est l'idée de garder les contrôleurs les plus simples et les plus petits possible, notamment
justement pour optimiser la réutilisation de code de nos modèles. C'est pour ça que quand j'ai
commencé cet épisode j'ai distingué le modèle MVC du terme architecture, parce que
c'est un patron de conception qui certes nous donne une structure pour la communication entre
chacun de ses composants mais la manière dont fonctionne chaque composant indépendamment peut
être différent, il peut y avoir plein de méthodes de faire. On peut par exemple imaginer que pour la
communication avec la base de données eh bien le modèle fonctionne grâce à de l'injection de
dépendance pour faire ce qu'on appelle de l'inversion contrôle et ça c'est aussi une grosse part de
ce qu'on appelle dans sa globalité l'architecture logicielle et pourtant qu'on fasse enfin qu'on
prenne cette solution ou non, ça ne remet absolument pas en question l'utilisation et la structure du
MVC. J'espère que cet épisode vous aura été utile et que ça vous aura un petit peu amélioré la
compréhension justement cette architecture. Moi je vous donne rendez-vous la semaine prochaine pour
un prochain épisode du podcast ou directement sur code-garrache.fr pour retrouver tous nos articles
de blog, tous nos épisodes de podcast et surtout toutes nos formations. Là il y a énormément de
nouvelles formations qui sortent très régulièrement. Je vous invite à y faire un tour parce qu'on
essaye de vous donner la meilleure qualité possible et les retours utilisateurs récompensent
vraiment ces efforts puisque on a très souvent des retours comme quoi même les personnes qui ont
eu des heures de cours spécialisés sur les sujets qu'on explique nous justement dans nos formations
et bien ils arrivent encore à trouver des informations inédites qu'ils avaient jamais
eu avant parce qu'on essaye toujours de creuser un petit peu plus en gardant un aspect vraiment de
vulgarisation pour que ça soit accessible à toutes et à tous. Je vous donne rendez-vous la
semaine prochaine pour un prochain épisode du podcast. Salut !