J'ai lu sur la conception MVC depuis un moment et il semble officiellement que la vue appelle des objets et des méthodes dans le modèle, construit et génère une vue.
Je pense que cela est principalement faux.
Le contrôleur doit agir et récupérer / mettre à jour des objets à l'intérieur du modèle, sélectionnez une vue appropriée et transmettez-la de l'information afin qu'elle puisse afficher. Seules les variables PHP brutes et rudimentaires / simples si les déclarations doivent apparaître à l'intérieur de la vue.
Si la vue reçoit les informations nécessaires à l'affichage du modèle, il y aura sûrement beaucoup de PHP à l'intérieur de la vue - violant complètement le point de logique de présentation séparée.
7 Réponses :
MVC n'est pas une loi dans la pierre. Selon l'endroit où vous l'avez lu, cela peut différer. Personnellement, je ne permettez pas à la vue de lire directement du modèle.
:)
Je pense que c'est mieux de voir la vue comme plus d'un modèle. Mvt comme j'aime le voir. Le seul inconvénient à avoir les informations récupérées du contrôleur et transmettre à la vue est que la vue dépend maintenant du contrôleur. La vue ne peut pas être appelée directement pour afficher une page, elle doit passer par le contrôleur - mais à nouveau, c'est l'ensemble but d'un contrôleur - pour réaliser des demandes HTTP GET / POST.
"Personnellement, je ne permet pas à la vision de lire directement du modèle." - Aussi lors de l'utilisation de Ajax?
@ M.PALLAZZO aussi. Les demandes AJAX sont toujours traitées par le contrôleur, pas directement par le modèle. Il n'y a pas de différence conceptuellement du point de vue du serveur entre une demande normale et une ajax une. La différence est dans la sortie et dans le client.
Il n'y a pas une façon absolue et correcte de faire MVC. Les variations sont possibles.
Par exemple, au lieu d'avoir l'opinion qui interrogeait activement le modèle, le contrôleur peut notifier l'affichage des modifications apportées dans le modèle, en utilisant une sorte de mécanisme de notification. Dans ce cas, la vue est juste à l'écoute des mises à jour, qui sont ensuite présentées.
MVC fait référence aux couches, pas de composants. Donc, ce sont des concepts plus abstraits que les plans. Comme il n'est pas vraiment possible de séparer entièrement les couches (les informations doivent couler entre eux), c'est vraiment un continuum où vous avez des spaghettis sur un système de type extrême et bureaucratique de l'autre. Vous voulez probablement trouver quelque part entre ces deux.
Je ne consacre généralement pas trop d'efforts sur la séparation du contrôleur. La séparation entre le modèle et la vue du contrôleur) est beaucoup plus importante.
Il est très important de séparer les fonctions du modèle de contrôleur et de vues, mais je pense que son avance relativement simple sachant ce qui appartient au modèle; Toutes les activités avec les données, la logique de banque, la validation, etc. Maintenant, la ligne entre la vue et le contrôleur, vous pourriez facilement vous retrouver avec le code SpageHetti.
Je pense que vous êtes absolument correct - les vues ne doivent pas appeler des méthodes à partir des modèles. Comme les autres l'a dit, il y a des variations sur MVC, mais le point qu'il doit séparer la logique des données de la sortie.
En règle générale, vous avez un contrôleur qui est le point de départ de l'application. Dans PHP, ce serait votre fichier index.php. Au minimum, ce fichier traiterait les données d'entrée (c'est-à-dire les paramètres de la chaîne de requête ou des URL). C'est généralement une bonne idée d'ajouter des contrôleurs séparés pour des parties séparées de l'application.
Chaque contrôleur décide simplement de quelles données doivent être affichées, l'obtiennent du modèle et le transmet à la vue. Dans PHP, vous appelleriez diverses classes / méthodes qui récupèrent des données de la base de données, le stockant dans des variables.
Ensuite, vous incluez simplement un autre fichier PHP contenant principalement du HTML, mais avec des variables écho PHP. Les boucles vont aussi bien. Si vous avez une liste de choses, vous voudrez peut-être faire quelque chose comme ceci:
Ce n'est probablement pas ce que l'on appellerait "pur" MVC, mais IMHO Ce n'est pas un accord énorme aussi longtemps que le code PHP de vue ne mutait pas le modèle. La règle la plus importante de MVC est que le modèle ne sait pas sur la vue. Avoir la vue ne pas savoir sur le modèle est moins important.
L'inconvénient principal d'utiliser directement le modèle est que la vue ne peut pas être réutilisée avec un modèle différent. Ceci est rarement un problème, car la vue est presque toujours spécifique à un type particulier d'objet de modèle (ou une liste de ceux-ci).
Comme avec tout ce qui est la programmation, nous devons être pragmatiques. Une vue ne doit contenir que la logique de présentation. Cette logique peut être très simple ou peut être assez complexe. Tant que cette logique ne gère que ce qui est affiché à l'écran, imprimé sur le rapport, etc.
Le contrôleur doit agir et récupérer / mettre à jour des objets à l'intérieur du modèle, sélectionnez une vue appropriée et transmettez-la afin qu'elle puisse afficher.
Quelle est ces informations que vous passez? Éventuellement un sous-ensemble d'un modèle. Vous pouvez créer une nouvelle classe contenant uniquement les informations que la vue doit connaître ou simplement passer le long du modèle et vous assurer que vous n'accédez que des données appropriées. Quoi qu'il en soit, la vue devrait être libre d'interroger ce modèle transmis pour pouvoir afficher une vue.
Le point de controverse est si vous de la vue doit pouvoir mettre à jour le modèle directement, contourner le contrôleur. C'est là que le côté pragmatique entre en place. Je pense que des cas peuvent justifier de mettre à jour le modèle directement. Surtout si vous pouvez utiliser des liaisons de données. Vous pouvez attribuer une zone de texte à une propriété du modèle et laissez la mise à jour d'automatiquement se produire automatiquement. S'il y a beaucoup de paramètres de propriété simples, cette approche peut enregistrer un tas de code dans le contrôleur. MVC n'est pas un ensemble de règles dans la pierre. Il s'agit des directives que lorsqu'elles sont utilisées correctement peuvent produire un meilleur code, mais si elle est utilisée trop de manière rigoureuse, peut entraîner une douleur et une souffrance.
être pragmatique!
Les modifications suivantes à Le code du code de disgruntetgoat soit considéré comme aussi "complexe"? Les objets doivent-ils être transmis à la vue? ou peut-être? P> <li><?=$item['description']?></li>
Le passage d'un objet ou d'une variable est une préférence de conception juste, bien que je balayais vers un tableau, car toutes mes données ne sont pas transmises à la vue seront déjà sous forme d'objet. J'aime garder les choses cohérentes sur mes points de vue, choisissez de toujours réussir par des objets ou des tableaux. Pour getDescription () Je dirais que cela dépend de ce que getDescription fait réellement. Si elle utilise une fonction d'assistance pour simplement format code de manière complexe, alors c'est bien. Bien que si cela provoque une requête SQL soit faite, ce n'est pas une bonne idée; C'est le travail du contrôleur pour obtenir les données des modèles.
Merci pour votre réponse. En pensant à un contrôleur transmettre des données pour afficher comme des objets plutôt que comme des tableaux, puis la complexité "rampante" résultante (accès d'attributs public remplacé par des méthodes) du PHP, lorsque des conseils semblent conserver le PHP Simple.