Pouvez-vous expliquer brièvement MVC ? Plus c'est simple, mieux c'est
滿天的星座2017-05-16 17:06:26
0
17
1299
J'ai récemment prévu d'apprendre le framework PHP, pour constater que ma compréhension précédente de MVC était très superficielle. Mais en regardant la documentation de Laravel, je suis toujours confus à propos de MVC
Par exemple, si vous écrivez une liste de tâches, suivez le MVC frontal et écrivez-la comme ceci :
Modèle : Un tableau JSON, correspondant au contenu de la base de données, qui est du texte, statut d'achèvement
Vue : modèle HTML, ou modèle DOM, qui est l'interface
Contrôleur : L'utilisateur opère sur l'interface puis modifie le modèle
En général, il existe une telle relation (pas très précise et les différentes implémentations MVC ne sont pas complètement cohérentes) :
L'ensemble du programme est mis à jour en fonction des changements de modèle
La vue est rendue en fonction du modèle et mise à jour au fur et à mesure que le modèle est mis à jour
Le contrôleur reçoit les déclencheurs d'événements dans View et modifie le modèle
C'est un cycle dans son ensemble~ Partir du modèle, ajouter les opérations utilisateur au milieu, puis revenir au modèle
C'est une idée pour écrire des graphiques, qui consiste à séparer les données de l'interface et à simplifier le programme.
En d'autres termes, faites abstraction du minimum de données représentant une interface en tant que modèle et du minimum d'opérations en tant que contrôleur.
La Vue change avec le Modèle, et peut même être modifiée à volonté en fonction des besoins de l'utilisateur.
Les réponses suivantes sont des opinions personnelles, veuillez me corriger si je me trompe.
Parlons d’abord du PHP natif.
Informatique, les pages sont affichées ensemble, imbriquées les unes dans les autres.
MVC est différent, le traitement des données et l'affichage sont séparés.
Lorsque l'affaire n'est pas compliquée, vous pouvez la gérer en gros avec V et C.
Frère C a traité les données, les a emballées et les a remises à V. Dites solennellement à V : « Frère V, les données sont toutes là, prenez-les et affichez-les ! »
V a dit : « D'accord, frère C ! » puis a affiché les données sur le front-end. Brother V a également une syntaxe similaire à foreach, qui est utilisée pour afficher les données fournies par Brother C.
Parfois, les affaires deviennent compliquées et Frère C est un peu fatigué de traiter les données seul, alors Frère C appelle Frère M pour l'aider.
Frère M aide Frère C à faire un travail répétitif et le confie au Frère C après s'en être occupé. Ensuite, le frère C le remettra au frère V.
Le PHP natif, c'est comme l'externalisation, souvent une seule personne doit gérer les choses front-end et back-end.
MVC est comme une entreprise mature, avec un front-end et un back-end. La division du travail est claire.
Tout le monde a parlé du concept. En fait, la signification de MVC a subtilement changé. Il existe une grande différence entre le MVC original du logiciel CS et le MVC du python ruby php d'aujourd'hui. Il est même possible que le concept soit devenu MVP depuis longtemps, mais tout le monde est habitué au MVC et l'a mal compris
Je pense qu'en termes de projets réels, vous pouvez comprendre approximativement l'essence et les objectifs de MVC en faisant trois expériences de pensée. Comment diviser spécifiquement les trois couches, qu'il s'agisse de trois couches, de quatre couches ou de deux couches, est en fait à réaliser. flexibilité et maintenabilité. C’est juste un moyen sexuel
.
Modifier la sélection de la base de données
La structure des données reste inchangée. Quel changement votre projet nécessite-t-il lors de la migration de la base de données de MySQL vers pgsql ou même mongodb ?
L'architecture MVC idéale ne devrait avoir besoin de modifier aucun code métier (y compris le modèle), il suffit de modifier le fichier de configuration et tout au plus d'écrire un nouveau pilote DBAL
Dans les situations réelles, il existe des différences subtiles dans les capacités des différentes bases de données, qui devraient être résolues en affinant le modèle.
Si votre réponse est aveugle : c'est presque la même chose que de la réécrire à nouveau, alors votre couche M n'est pas assez indépendante, et il est temps de disperser le code écrit dans le Modèle ailleurs
Version HTML5 mobile
En supposant que toutes les fonctions restent inchangées (toutes ont des interactions raisonnables et naturelles avec la version mobile) et que vous ajoutez une version mobile à votre site, quel changement votre projet nécessitera-t-il ?
La réponse devrait être de réécrire un ensemble de vues, puis de remplacer le contrôleur par une seule ligneif(isMobile) use(MobileView);
Si vous constatez que le contrôleur doit changer beaucoup de logique, et que même le modèle est impliqué, alors votre couche V n'est pas assez indépendante
API ajoutée
En supposant que toutes les fonctions restent inchangées, de combien de changements votre projet aura-t-il besoin pour ajouter une API ouverte à votre site (pour une utilisation par des tiers ou des applications mobiles) ?
La réponse devrait être un nouvel ensemble de contrôleurs contenant une nouvelle autorisation, un nouveau format de données et une nouvelle logique de vérification, ainsi qu'une vue simple (ne produisant que du json ou du xml)
Si vous constatez que le modèle doit être modifié, que certains éléments de la vue d'origine doivent être déplacés ou qu'une partie du code initialement écrit dans l'ancien contrôleur doit être copiée, alors votre couche C n'est pas suffisamment indépendante
La chose la plus frappante et la plus simple est de comparer MVC à la console de jeu à cartes à laquelle nous jouions quand nous étions enfants :
M : C'est la carte de jeu, enregistre les données, est responsable de la logique métier, etc.
V : C'est la télé, chargée de présenter l'écran de jeu
C : C'est la poignée de contrôle du jeu, responsable de l'interaction entre les deux premiers
Prenons l'exemple d'un site Web commercial.
M fournit un modèle de données. Par exemple, les données utilisateur du site Web comprennent le nom d'utilisateur, le mot de passe et l'adresse e-mail. Chaque utilisateur peut passer plusieurs commandes, et chaque commande a un numéro de commande, un prix, etc.
V fournit une vue à quoi ressemble l'interface HTML que vous voyez, comme la présentation des listes de produits et la présentation des commandes historiques personnelles.
C est le contrôleur, chargé d'extraire les données de M puis de les présenter dans V. Par exemple, lorsque vous souhaitez consulter l'historique de vos commandes personnelles de la semaine dernière, V est chargé de rechercher toutes vos commandes de M, de filtrer les données de commande d'il y a une semaine, puis de fournir le reste à V pour affichage.
La condition préalable à la compréhension de MVC est le concept de superposition de code, et le but de la superposition de code est le découplage.
Veuillez essayer de répondre à deux questions :
Pourquoi le code devrait-il être découplé ?
Comment découpler ?
Pourquoi le code doit être découplé
Un logiciel commence par le déclenchement par l'utilisateur de l'exigence métier sur la vue, jusqu'au programme traitant l'exigence selon une certaine logique métier, puis jusqu'au résultat du traitement renvoyé à l'utilisateur sur la vue. Le code dans l'ensemble du processus est. responsable de trois tâches principales, à savoir : les opérations de vue, le traitement de la logique métier et la connexion entre les vues et la logique métier.
Si le code n'est pas superposé dans le programme, alors la mise en œuvre de ces trois aspects sera couplée dans une seule classe. Pour la maintenabilité, la lisibilité et la flexibilité du code (veuillez vous référer à la réponse de @mcfog), ces codes doivent être écrits dans différentes classes selon les aspects, puis les classes avec les mêmes aspects doivent être placées dans un package. comme s'ils étaient à des niveaux différents.
Comment découpler
mvc est une solution mature en couches (découplée).
Selon la réponse à la première question, vous devez mettre différents niveaux de code dans différentes classes (et packages), alors comment ces différents niveaux de code collaborent-ils ?
D'autres réponses à cette question semblent avoir répondu à cette question de manière spécifique et avec des images et des textes.
Le code du modèle est responsable de la logique métier ;
Le code dans la vue est responsable de l'interaction de l'utilisateur ;
Le code dans le contrôleur est responsable de la connexion entre le modèle et la vue.
Model View Modèle de contrôleur, vue, contrôleur
Modèle : Modèle de données
Vue : éléments liés à l'interface utilisateur
Contrôleur : utilisé pour connecter le modèle et la vue
M : Modèle - comment modélisez-vous les données ou quelle structure est utilisée pour représenter vos données
C : Contrôleur - comment vous traitez la logique métier. Ce « traitement » correspond principalement à deux fins : l'une consiste à demander la source de données requise pour le traitement à partir du modèle ; l'autre extrémité consiste à transmettre les résultats du traitement à la vue dans certains ; manière ; Le processus spécifique au milieu est le niveau dont le contrôleur est responsable
V : Vue - comment vous présentez les résultats du traitement commercial au client et fournissez une interaction
En fait, il n'est pas bon de le dire trop simplement, car certains détails ne peuvent être que très résumés et abstraits par souci de simplicité, sans connaissances et expériences suffisantes pour le soutenir, c'est comme voir des fleurs dans le brouillard.
Après avoir lu les réponses de tout le monde ci-dessus, j'ai finalement réalisé : V est destiné aux utilisateurs à voir, C est à contrôler par les utilisateurs et M est inaccessible aux utilisateurs. M peut-il être contrôlé via C et V ?
Discussion sur MVC sur SO : Qu'est-ce que MVC, vraiment ?
Pour faire simple, ne mélangez pas le code base de données (Modèle) et le code affichage des données (Vue) S'il y a une logique métier qui doit être ajoutée, c'est le Contrôleur (Contrôleur).
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Par exemple, si vous écrivez une liste de tâches, suivez le MVC frontal et écrivez-la comme ceci :
En général, il existe une telle relation (pas très précise et les différentes implémentations MVC ne sont pas complètement cohérentes) :
C'est un cycle dans son ensemble~ Partir du modèle, ajouter les opérations utilisateur au milieu, puis revenir au modèle
C'est une idée pour écrire des graphiques, qui consiste à séparer les données de l'interface et à simplifier le programme.
En d'autres termes, faites abstraction du minimum de données représentant une interface en tant que modèle et du minimum d'opérations en tant que contrôleur.
La Vue change avec le Modèle, et peut même être modifiée à volonté en fonction des besoins de l'utilisateur.
en gros :
ou :
Les réponses suivantes sont des opinions personnelles, veuillez me corriger si je me trompe.
Parlons d’abord du PHP natif.
Informatique, les pages sont affichées ensemble, imbriquées les unes dans les autres.
MVC est différent, le traitement des données et l'affichage sont séparés.
Lorsque l'affaire n'est pas compliquée, vous pouvez la gérer en gros avec V et C.
Frère C a traité les données, les a emballées et les a remises à V. Dites solennellement à V : « Frère V, les données sont toutes là, prenez-les et affichez-les ! »
V a dit : « D'accord, frère C ! » puis a affiché les données sur le front-end. Brother V a également une syntaxe similaire à foreach, qui est utilisée pour afficher les données fournies par Brother C.
Parfois, les affaires deviennent compliquées et Frère C est un peu fatigué de traiter les données seul, alors Frère C appelle Frère M pour l'aider.
Frère M aide Frère C à faire un travail répétitif et le confie au Frère C après s'en être occupé. Ensuite, le frère C le remettra au frère V.
Le PHP natif, c'est comme l'externalisation, souvent une seule personne doit gérer les choses front-end et back-end.
MVC est comme une entreprise mature, avec un front-end et un back-end. La division du travail est claire.
Tout le monde a parlé du concept. En fait, la signification de MVC a subtilement changé. Il existe une grande différence entre le MVC original du logiciel CS et le MVC du python ruby php d'aujourd'hui. Il est même possible que le concept soit devenu MVP depuis longtemps, mais tout le monde est habitué au MVC et l'a mal compris
Je pense qu'en termes de projets réels, vous pouvez comprendre approximativement l'essence et les objectifs de MVC en faisant trois expériences de pensée. Comment diviser spécifiquement les trois couches, qu'il s'agisse de trois couches, de quatre couches ou de deux couches, est en fait à réaliser. flexibilité et maintenabilité. C’est juste un moyen sexuel
.Modifier la sélection de la base de données
La structure des données reste inchangée. Quel changement votre projet nécessite-t-il lors de la migration de la base de données de MySQL vers pgsql ou même mongodb ?
L'architecture MVC idéale ne devrait avoir besoin de modifier aucun code métier (y compris le modèle), il suffit de modifier le fichier de configuration et tout au plus d'écrire un nouveau pilote DBAL
Dans les situations réelles, il existe des différences subtiles dans les capacités des différentes bases de données, qui devraient être résolues en affinant le modèle.
Si votre réponse est aveugle : c'est presque la même chose que de la réécrire à nouveau, alors votre couche M n'est pas assez indépendante, et il est temps de disperser le code écrit dans le Modèle ailleurs
Version HTML5 mobile
En supposant que toutes les fonctions restent inchangées (toutes ont des interactions raisonnables et naturelles avec la version mobile) et que vous ajoutez une version mobile à votre site, quel changement votre projet nécessitera-t-il ?
La réponse devrait être de réécrire un ensemble de vues, puis de remplacer le contrôleur par une seule ligne
if(isMobile) use(MobileView);Si vous constatez que le contrôleur doit changer beaucoup de logique, et que même le modèle est impliqué, alors votre couche V n'est pas assez indépendante
API ajoutée
En supposant que toutes les fonctions restent inchangées, de combien de changements votre projet aura-t-il besoin pour ajouter une API ouverte à votre site (pour une utilisation par des tiers ou des applications mobiles) ?
La réponse devrait être un nouvel ensemble de contrôleurs contenant une nouvelle autorisation, un nouveau format de données et une nouvelle logique de vérification, ainsi qu'une vue simple (ne produisant que du json ou du xml)
Si vous constatez que le modèle doit être modifié, que certains éléments de la vue d'origine doivent être déplacés ou qu'une partie du code initialement écrit dans l'ancien contrôleur doit être copiée, alors votre couche C n'est pas suffisamment indépendante
La chose la plus frappante et la plus simple est de comparer MVC à la console de jeu à cartes à laquelle nous jouions quand nous étions enfants :
M : C'est la carte de jeu, enregistre les données, est responsable de la logique métier, etc.
V : C'est la télé, chargée de présenter l'écran de jeu
C : C'est la poignée de contrôle du jeu, responsable de l'interaction entre les deux premiers
Prenons l'exemple d'un site Web commercial.
M fournit un modèle de données. Par exemple, les données utilisateur du site Web comprennent le nom d'utilisateur, le mot de passe et l'adresse e-mail. Chaque utilisateur peut passer plusieurs commandes, et chaque commande a un numéro de commande, un prix, etc.
V fournit une vue à quoi ressemble l'interface HTML que vous voyez, comme la présentation des listes de produits et la présentation des commandes historiques personnelles.
C est le contrôleur, chargé d'extraire les données de M puis de les présenter dans V. Par exemple, lorsque vous souhaitez consulter l'historique de vos commandes personnelles de la semaine dernière, V est chargé de rechercher toutes vos commandes de M, de filtrer les données de commande d'il y a une semaine, puis de fournir le reste à V pour affichage.
La condition préalable à la compréhension de MVC est le concept de superposition de code, et le but de la superposition de code est le découplage.
Veuillez essayer de répondre à deux questions :
Pourquoi le code doit être découplé
Un logiciel commence par le déclenchement par l'utilisateur de l'exigence métier sur la vue, jusqu'au programme traitant l'exigence selon une certaine logique métier, puis jusqu'au résultat du traitement renvoyé à l'utilisateur sur la vue. Le code dans l'ensemble du processus est. responsable de trois tâches principales, à savoir : les opérations de vue, le traitement de la logique métier et la connexion entre les vues et la logique métier.
Si le code n'est pas superposé dans le programme, alors la mise en œuvre de ces trois aspects sera couplée dans une seule classe. Pour la maintenabilité, la lisibilité et la flexibilité du code (veuillez vous référer à la réponse de @mcfog), ces codes doivent être écrits dans différentes classes selon les aspects, puis les classes avec les mêmes aspects doivent être placées dans un package. comme s'ils étaient à des niveaux différents.
Comment découpler
mvc est une solution mature en couches (découplée).
Selon la réponse à la première question, vous devez mettre différents niveaux de code dans différentes classes (et packages), alors comment ces différents niveaux de code collaborent-ils ?
D'autres réponses à cette question semblent avoir répondu à cette question de manière spécifique et avec des images et des textes.
Le code du modèle est responsable de la logique métier ; Le code dans la vue est responsable de l'interaction de l'utilisateur ; Le code dans le contrôleur est responsable de la connexion entre le modèle et la vue.
Model View Modèle de contrôleur, vue, contrôleur
Modèle : Modèle de données
Vue : éléments liés à l'interface utilisateur
Contrôleur : utilisé pour connecter le modèle et la vue
Plus c’est simple, mieux c’est, non ?
M : Modèle - comment modélisez-vous les données ou quelle structure est utilisée pour représenter vos données
C : Contrôleur - comment vous traitez la logique métier. Ce « traitement » correspond principalement à deux fins : l'une consiste à demander la source de données requise pour le traitement à partir du modèle ; l'autre extrémité consiste à transmettre les résultats du traitement à la vue dans certains ; manière ; Le processus spécifique au milieu est le niveau dont le contrôleur est responsable
V : Vue - comment vous présentez les résultats du traitement commercial au client et fournissez une interaction
En fait, il n'est pas bon de le dire trop simplement, car certains détails ne peuvent être que très résumés et abstraits par souci de simplicité, sans connaissances et expériences suffisantes pour le soutenir, c'est comme voir des fleurs dans le brouillard.
Après avoir lu les réponses de tout le monde ci-dessus, j'ai finalement réalisé : V est destiné aux utilisateurs à voir, C est à contrôler par les utilisateurs et M est inaccessible aux utilisateurs. M peut-il être contrôlé via C et V ?
Discussion sur MVC sur SO : Qu'est-ce que MVC, vraiment ?
Pour faire simple, ne mélangez pas le code base de données (Modèle) et le code affichage des données (Vue) S'il y a une logique métier qui doit être ajoutée, c'est le Contrôleur (Contrôleur).