Share
Model-View-Controller (MVC) est probablement l'un des modèles les plus cités dans le monde de la programmation Web ces dernières années. Quiconque travaille actuellement dans le domaine du développement d'applications Web aura entendu ou lu l'acronyme des centaines de fois. Aujourd'hui, nous allons clarifier ce que signifie MVC et pourquoi il est devenu si populaire.
MVC n'est pas un modèle de conception, c'est un modèle architectural qui décrit un moyen de structurer notre application, ainsi que les responsabilités et les interactions de chaque partie de cette structure..
Il a été décrit pour la première fois en 1979 et, évidemment, le contexte était un peu différent. Le concept d'application web n'existait pas. Tim Berners Lee a semé les graines du World Wide Web au début des années 90 et a changé le monde pour toujours. Le modèle que nous utilisons aujourd'hui pour le développement Web est une adaptation du modèle original..
La vulgarisation sauvage de cette structure pour les applications Web est due à son inclusion dans deux cadres de développement devenus immensément populaires: Struts et Ruby on Rails. Ces deux environnements ont ouvert la voie aux centaines de frameworks créés plus tard.
L'idée du modèle architectural Vue-Contrôleur-Modèle est simple: nous devons clairement séparer les responsabilités suivantes dans notre application:
L'application est divisée en trois composantes principales, chacune chargée de tâches différentes. Voyons une explication détaillée et un exemple.
le Manette gère les demandes de l'utilisateur (reçues sous forme de demandes HTTP GET ou POST lorsque l'utilisateur clique sur des éléments de l'interface graphique pour effectuer des actions). Sa fonction principale est d'appeler et de coordonner les ressources / objets nécessaires à l'exécution de l'action de l'utilisateur. Habituellement, le contrôleur appelle le modèle approprié pour la tâche, puis sélectionne la vue appropriée..
le Modèle sont les données et les règles applicables à ces données, qui représentent des concepts gérés par l'application. Dans tout système logiciel, tout est modélisé comme des données que nous traitons d'une certaine manière. Qu'est-ce qu'un utilisateur, un message ou un livre pour une application? Seules les données qui doivent être traitées selon des règles spécifiques (la date ne peut pas être ultérieure, les messages électroniques doivent avoir un format spécifique, le nom ne peut pas dépasser x caractères, etc.).
Le modèle donne au contrôleur une représentation de données de ce que l'utilisateur a demandé (un message, une liste de livres, un album photo, etc.). Ce modèle de données sera le même quelle que soit la manière dont nous souhaitons le présenter à l'utilisateur. C'est pourquoi nous pouvons choisir n'importe quelle vue disponible pour le rendre..
Le modèle contient la partie la plus importante de notre logique d'application, la logique qui s'applique au problème auquel nous sommes confrontés (un forum, un magasin, une banque, etc.). Le contrôleur contient une logique plus interne d’organisation pour l’application elle-même (plutôt comme une gestion interne).
le Vue fournit différentes façons de présenter les données reçues du modèle. Ils peuvent être des modèles où ces données sont remplies. Il peut y avoir plusieurs vues différentes et le contrôleur doit décider lequel utiliser.
Une application Web est généralement composée d'un ensemble de contrôleurs, de modèles et de vues. Le contrôleur peut être structuré comme un contrôleur principal qui reçoit toutes les demandes et appelle des contrôleurs spécifiques qui gèrent des actions pour chaque cas..
Supposons que nous développions une librairie en ligne. L'utilisateur peut effectuer des actions telles que: afficher des livres, enregistrer, acheter, ajouter des articles à la commande en cours, créer ou supprimer des livres (s'il est administrateur, etc.). Voyons ce qui se passe lorsque l'utilisateur clique sur le bouton fantaisie catégorie pour voir les titres disponibles.
Nous aurons un contrôleur particulier pour gérer toutes les actions liées aux livres (voir, éditer, créer, etc.). Appelons-le books_controller.php pour cet exemple. Nous aurons également un modèle, par exemple book_model.php, traitant les données et la logique liées aux articles de la boutique. Enfin, nous aurons une série de vues pour présenter, par exemple, une liste de livres, une page pour éditer des livres, etc..
La figure suivante montre comment l'utilisateur demande de visualiser la liste des livres de fantasy:
Le contrôleur (books_controller.php) reçoit la demande de l'utilisateur [1] en tant que requête HTTP GET ou POST (nous pouvons également avoir un contrôleur central, par exemple index.php le recevant puis appelant books_controller.php)..
Le contrôleur examine la demande et les paramètres et appelle le modèle (book_model.php) demandant lui de retourner la liste des livres de fantasy disponibles [2].
Le modèle est chargé d'extraire ces informations de la base de données (ou de l'endroit où elles sont stockées) [3], d'appliquer des filtres ou une logique si nécessaire et de renvoyer les données représentant la liste des livres [4]..
Le contrôleur utilisera la vue appropriée [5] pour présenter ces données à l'utilisateur [6-7]. Si la demande provient d'un téléphone mobile, une vue pour téléphones mobiles sera utilisée, si l'utilisateur a sélectionné un skin particulier, la vue correspondante sera choisie, etc..
L'avantage le plus évident que nous obtenons avec MVC est une séparation claire de la présentation (l'interface avec l'utilisateur) et de la logique d'application..
La prise en charge de différents types d’utilisateurs utilisant différents types de périphériques est un problème courant de nos jours. L'interface présentée doit être différente si la demande provient d'un ordinateur de bureau ou d'un téléphone portable. Le modèle renvoie exactement les mêmes données, la seule différence est que le contrôleur choisira une vue différente pour les rendre (nous pouvons penser à un modèle différent)..
Outre qu'elle isole la vue de la logique métier, la séparation M-V-C réduit la complexité lors de la conception d'applications volumineuses. Le code est beaucoup plus structuré et donc plus facile à maintenir, à tester et à réutiliser.
Lorsque vous utilisez une structure, la structure de base de MVC est déjà prête et il vous suffit d'étendre cette structure, en plaçant vos fichiers dans le répertoire approprié, afin de respecter le modèle Model-View-Controller. De plus, vous obtenez beaucoup de fonctionnalités déjà écrites et testées de manière approfondie.
Prenez cakePHP comme exemple de framework MVC. Une fois que vous l'avez installé, vous verrez trois répertoires principaux:
le app le dossier est l'endroit où vous placez vos fichiers. C'est votre place pour développer votre partie de l'application.
le gâteau le dossier est l'endroit où cakePHP a ses fichiers et où ils ont développé leur partie (fonctionnalité principale du framework).
le vendeurs le dossier est destiné aux bibliothèques PHP tierces si nécessaire.
Votre lieu de travail (répertoire app) a la structure suivante:
Maintenant, vous devez mettre vos contrôleurs dans le contrôleurs répertoire, vos modèles dans le des modèles répertoire et vos vues dans… le vues annuaire!
Une fois que vous serez habitué à votre framework, vous saurez où chercher presque tous les éléments de code que vous devez modifier ou créer. Cette organisation seule rend la maintenabilité beaucoup plus facile.
Étant donné que ce didacticiel n'a pas pour objectif de vous montrer comment créer une application à l'aide de cakePHP, nous ne l'utiliserons que pour montrer un exemple de code pour les composants de modèle, de vue et de contrôleur et pour commenter les avantages de l'utilisation d'un framework MVC. Le code est trop simpliste et ne convient pas aux applications réelles.
Rappelez-vous que nous avions une librairie et un utilisateur curieux qui voulait voir la liste complète des livres dans le fantaisie Catégorie. Nous avons dit que le responsable du traitement sera celui qui recevra la demande et coordonnera les actions nécessaires.
Ainsi, lorsque l'utilisateur clique dessus, le navigateur demande cette URL:
www.ourstore.com/books/list/fantasy
CakePHP aime formater les URL sous la forme / controller / action / param1 / param2, où action est la fonction à appeler dans le contrôleur. Dans l'ancien format classique, il s'agirait de:
www.ourstore.com/books_controller.php?action=list&category=fantasy
Avec l'aide de la structure cakePHP, notre contrôleur ressemblera à ceci:
Accentsconagua
set ('livres', $ this-> Book-> findAllByCategory ($ catégorie)); fonction add () … fonction delete () ……?> Simple, n'est-ce pas? Ce contrôleur sera enregistré sous le nom books_controller.php et placé dans / app / controllers. Il contient la fonction de liste, pour effectuer l'action dans notre exemple, mais également d'autres fonctions pour effectuer d'autres actions liées au livre (ajouter un nouveau livre, supprimer un nouveau livre, etc.)..
Le framework fournit beaucoup de choses pour nous et une seule ligne suffit pour lister les livres. Nous avons des classes de base avec le comportement de base du contrôleur déjà défini, nous en héritons donc (AppController qui hérite de Controller).
Dans l'action de liste, tout ce qu'il a à faire est d'appeler le modèle pour obtenir les données, puis de choisir une vue pour la présenter à l'utilisateur. Expliquons comment cela se fait.
this-> Réserver est notre modèle, et cette partie:
$ this-> Book-> findAllByCategory ($ catégorie)
demande au modèle de renvoyer la liste des livres de la catégorie sélectionnée (nous verrons le modèle plus tard).
le ensemble méthode dans la ligne:
$ this-> set ('livres', $ this-> Book-> findAllByCategory ($ category)); Le moyen utilisé par le contrôleur pour transmettre des données à la vue. Il définit le livres variable aux données renvoyées par le modèle et le rend accessible à la vue.
Il ne reste plus qu'à rendre la vue, mais cela sera fait automatiquement par CakePHP si nous voulons la vue par défaut. Si nous avons besoin d’une autre vue, nous devons simplement l’appeler explicitement à l’aide de la touche rendre méthode.
Le modèle est encore plus simple:
Pourquoi vide? Parce qu'elle hérite d'une classe de base qui fournit les fonctionnalités nécessaires et que nous avons suivi les conventions de noms de CakePHP pour permettre au framework d'effectuer d'autres tâches automatiquement. Par exemple, cakePHP sait, en fonction des noms, que ce modèle est utilisé dans BooksController et qu'il accédera à une table de base de données appelée books..
Avec cette déclaration seulement, nous avons un modèle de livre capable de lire, supprimer ou sauvegarder des données de la base de données.
Le code sera enregistré en tant que book.php et placé dans / app / models.
Il ne reste plus qu'à créer une vue (au moins une) pour l'action liste. La vue contiendra le code HTML et quelques lignes (le moins possible) de PHP pour parcourir le tableau de livres fourni par le modèle..
| Titre | Auteur | Prix |
|---|---|---|
Comme on peut le constater, la vue ne produit pas une page complète, mais un fragment HTML (un tableau dans ce cas). Ceci est dû au fait que CakePHP fournit un autre moyen de définir la mise en page de la page et que les vues sont insérées dans cette mise en page. Le framework nous fournit également des objets d'aide pour faciliter la tâche commune lors de la création de ces extraits HTML (insérer des formulaires, des liens, Ajax ou JavaScript)..
Nous en faisons la vue par défaut en l'enregistrant sous list.ctp (list est le nom de l'action et ctp signifie modèle de gâteau) et en le plaçant dans / app / views / books (à l'intérieur des livres car il s'agit de vues pour les actions du contrôleur de livres).
Et cela complète les trois composants avec l'aide du framework CakePHP!
Nous avons appris quel est probablement le modèle architectural le plus couramment utilisé aujourd'hui. Nous devons toutefois être conscients que lorsque nous parlons de modèles dans le monde de la programmation, nous parlons de cadres flexibles, pour être adaptés au problème particulier à résoudre. Nous trouverons des implémentations qui introduisent des variations de la structure que nous avons vue, mais l’important est qu’en fin de compte, le modèle nous aide à établir une distinction claire entre les responsabilités et à améliorer la maintenabilité, la réutilisation du code et les tests..
Nous avons également constaté les avantages de l’utilisation d’un framework MVC qui nous fournit un squelette MVC de base et de nombreuses fonctionnalités, ce qui améliore notre productivité et facilite le processus de développement. Merci d'avoir lu!
