J'essaie d'apprendre et de bien comprendre le modèle MVC et d'apprendre PHP en même temps. J'ai décidé de construire un cadre MVC de base que je pourrais utiliser sur divers projets plus tard. Ayant lu beaucoup de poteaux ici concernant MVC et couplage entre modèles / vues / contrôleurs, je suis un peu perdu. Pour le moment, je crois comprendre que dans les contrôleurs d'applications Web traitent de la demande à venir du navigateur et, si nécessaire, des méthodes d'appels sur classes de modèle racontant des modèles de changer d'état. Ensuite, le contrôleur instanciez la classe d'affichage appropriée qui sera responsable de l'affichage de l'interface. Voici le peu que je ne comprends pas ...
MAINTENANT DEVRAIT PASSURER L'objet de modèle approprié pour afficher et afficher doit retirer toutes les données du modèle si nécessaire?
ou contrôleur doit saisir des données à partir du modèle et la transmettre à la vue, éventuellement tout en l'enveloppant dans un seul objet wrapper que la vue permettra d'accéder et de saisir des données de là?
ou la vue doit simplement instancer le modèle approprié lorsque cela est nécessaire et retirez les données directement à partir de l'objet modèle?
de ce que j'ai lu ici
http://www.phpwact.org/pattern/model_view_controller
Je me pencherais vers la 3ème option où le contrôleur ne transmet rien pour voir et voir les instanciateurs, il a besoin. C'est parce que:
La vue et le contrôleur doivent avoir le même accès au modèle
contrôleur ne devrait pas agir simplement comme médiateur entre la vue et le modèle.
y a-t-il vraiment un moyen correct de le faire ou cela dépend plutôt du projet? De plus, quelle approche recommanderiez-vous à quelqu'un qui a une compréhension décente de OOP mais est relativement nouveau à PHP et pas trop clair sur l'architecture MVC. Ou peut-être que je devrais aller avec tout ce qui me semble juste et apprenez de mes erreurs (aimerait éviter celui-ci;)?
Maintenant, laissez-moi savoir si ma question n'est pas claire essaiera de mieux expliquer .. Aussi, j'ai lu beaucoup de messages sur Stackoverflow et de nombreux articles sur différents sites, mais j'apprécierais toujours l'aide pour toutes les réponses. .
8 Réponses :
Personnellement, j'ai toujours été promoteur de # 2. La vue ne devrait pas se soucier du modèle. La vue ne devrait pas avoir de traitement du tout à ce sujet. Il devrait faire ce qu'il est censé faire, formater des données.
Le flux de contrôle de base doit donc être: le contrôleur reçoit une demande d'un navigateur. Il traite la demande, décide des données nécessaires et la récupère à partir du modèle / s. Il transmet ensuite les données dans la vue qui format les données et l'affiche.
comme une extension, l'entrée de l'utilisateur est traitée à l'intérieur du contrôleur et enregistrée dans un modèle si nécessaire, puis la rétroaction est introduite dans une vue, etc. Le point de départ de la clé à emporter est que le traitement se produit à l'intérieur du contrôleur.
Je suis avec Matthew sur celui-ci. Le contrôleur devrait être responsable de tout ce qui se passe entre la vue et le modèle. Si ce n'est pas le cas, alors pourquoi l'appelleraient-ils 'contrôleur'? ; P
Le contrôleur et la vue ne doivent pas parler du tout en MVC. La logique commerciale réside dans le modèle, pas le contrôleur. Le faire comme vous l'avez suggéré rendrait tout le centre autour du contrôleur au lieu de trouver trois parties distinctes - MVC!
J'ai eu une question très similaire plus tôt. Je trouve utile de penser à cela comme suit: Vous utiliseriez MVC plus souvent dans des applications non Web, où de nombreuses classes interagissent avec elles-mêmes simultanées. Dans une application Web MVC signifie MVT (modèle de vue de modèle) donc dans une application Web La présentation est traitée dans le modèle, la logique de l'application est manipulée dans La vue (ou les classes appelées par la vue), et le modèle est responsable de la détention de données.
Le nom MVT est affreux. En informatique, affichage signifie contrôleur ou contrôleur + vue.
Qu'en est-il de la MCT, je veux dire pourquoi prendre le contrôleur sortit, il aurait la même fonction de traitement de la saisie de l'utilisateur, même dans une application Web
Web MVC et MVC de bureau sont deux bêtes très différentes.
Dans Web MVC, un lien dans une vue appelle une méthode sur un contrôleur, qui met à jour un modèle, puis redirige vers une vue appropriée, qui ouvre un modèle et montre ce dont il a besoin.
dans un ordinateur de bureau MVC, l'option 3 est erronée car la vue et le modèle doivent utiliser la même référence. Dans Web, il n'y a pas de choix.
option numéro 2 n'est pas MVC. C'est MVP, dans lequel le présentateur est un médiateur.
Un contrôleur a un accès en écriture à un modèle; Une vue n'a qu'un accès en lecture.
Je pense que c'est une réponse importante, lorsque vous passez dans # 2 Data MVP, la vue ne peut pas modifier les données, sinon il aurait un accès en écriture comme vous l'avez mentionné et je ne pense pas que ce serait bien du point d'immuabilité au moins pour le Web. Applications, alors que les applications traitent et tentent d'atteindre exactement cette voie de communication.
C'est une question très intéressante. De mon expérience, la plupart des implémentations de PHP attribuent une variable de modèle à la vue:
//in the controller file $this->view->myObject = $modelObj; //in the view file, you could call an object modifying method $this->myObject->delete();
C'est un argument super tueur! Excellente réponse! Pourquoi n'est-ce pas la réponse acceptée?
Personnellement, j'ai toujours été un promoteur de # 3. La vue ne devrait pas se soucier du contrôleur. La vue ne devrait pas avoir de dépendance au contrôleur à ce sujet. Il devrait faire ce qu'il est censé faire, montrer une vue du modèle.
Le flux de contrôle de base doit donc être: le contrôleur reçoit une demande d'un navigateur. Il rend les mises à jour du modèle, qui est pertinente, puis sélectionne une vue. Le contrôle est ensuite transmis à la vue, qui obtient des données du modèle et le rend.
En tant qu'extension, l'entrée utilisateur peut être considérée comme une partie du modèle, et le contrôleur et la vue peuvent en lire. Le point de vue de la clé à emporter est que le contrôleur et la vision ne devraient avoir aucune dépendance les uns sur les autres. C'est pourquoi le motif s'appelle MVC.
Maintenant, personnellement, je trouve MVC un peu trop fastidieux, et donc je confond habituellement le contrôleur et affiche plus que cela. Mais alors ce n'est pas vraiment mvc.
Mais que faisons-nous si il faut 2 modèles? Je ne sais pas si cela se passe ou pourrait même être une mauvaise architecture, mais cela ressemble à un cas possible.
Sûr. Lorsque vous parlez de "la vue" et du "le modèle" dans le singulier, nous nous référons vraiment aux différentes couches. La mise en œuvre effective pourrait invoquer plusieurs classes / objets dans cette couche. Par exemple, "une vue" est souvent une collection de plusieurs fragments partiels qui se réunissent pour rendre le résultat final. De même, vous pouvez souvent utiliser plusieurs objets de modèle dans le processus.
J'ai tendance à avoir le contrôleur agir comme un intermédiaire entre le modèle et la vue, mais il s'agit généralement d'une seule ligne de code qui relie les trois ensemble. Si votre modèle, votre affichage et votre contrôleur sont correctement découplés, il devrait faire très peu de différence que vous utilisez.
Je pense que ce n'est qu'une argume générique sur ce qui est meilleur "push" ou "tirez" modèle. Il n'y a pas de meilleure solution "absolument".
La raison pour laquelle tant de développeurs d'aujourd'hui ne peuvent pas obtenir le cocal de MVC, c'est que l'abréviation de MVC a été mal indiquée du jour où elle est arrivée dans le développement de logiciels, mais le concept est correct à l'époque et aujourd'hui. Depuis que je suis de la vieille école, laissez-moi vous expliquer pour vous; Lorsque vous créez un objet, vous créez d'abord un modèle afin que le client puisse le voir, une fois qu'il est approuvé, vous aurez le contrôle total sur la manière dont l'objet sera effectué. C'est ainsi que c'est à ce jour dans la fabrication de produits.
Dans le développement d'applications Web d'aujourd'hui, ce terme devrait être VCM. Pourquoi! Vous voyez ce qui est sur le navigateur Web, puis vous cliquez sur un bouton pour action, appelé contrôleur. Le contrôleur alerte le modèle, qui est l'instruction ou la logique pour produire un résultat (c'est votre script). Le résultat est ensuite renvoyé à l'utilisateur pour la visualisation. Dans l'ingénierie logicielle, vous pouvez y référer en tant que cmv; Parce que l'utilisateur ne peut rien afficher jusqu'à ce que les applications soient compilées et installées. Nous aurons donc besoin d'un appareil de contrôle (PC); Le système d'exploitation comme modèle et un moniteur pour afficher les résultats. Si vous pouvez comprendre ces concepts, MVC devrait commencer à regarder beaucoup plus appétissant. J'espère que ce concept aidera quelqu'un à comprendre MVC.