Maison > Article > développement back-end > Analyse de l'architecture MVC dans le framework PHP (avec exemples)
Le contenu de cet article concerne l'analyse de l'architecture MVC dans le framework PHP (avec des exemples). Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer.
Avant de parler de l’architecture MVC, parlons d’abord du framework PHP. De très nombreuses personnes ayant appris le langage PHP sont confrontées à différents frameworks PHP. Qu'en est-il de TP, Yii, CI et du très populaire Laravel, etc.
La plupart d'entre eux diront qu'ils sont basés sur l'architecture MVC, et ensuite il faut essayer de comprendre la logique de MVC, et essayer d'utiliser cette logique pour construire un site Web, et ensuite ils diront que MVC est vraiment délicieux~
Entretien
Dans de nombreuses interviews PHP, des questions sur MVC peuvent être posées, telles que ce que signifie MVC et comment comprendre cette architecture. Cependant, beaucoup de gens comprennent que le modèle est un modèle qui correspond à la structure des tables dans la base de données ; la vue correspond à la page et est utilisée pour l'affichage ; le contrôleur est principalement utilisé pour écrire diverses logiques et associer des données à l'affichage de la page.
Il n'y a fondamentalement aucun problème avec la réponse ci-dessus, mais la structure d'un site Web est-elle vraiment aussi simple ? Évidemment pas
Design
Avant cela, comprenons d'abord l'un des modèles de conception : le modèle médiateur. Une compréhension frappante est : l'adaptateur entre la prise de la Banque de Hong Kong et la prise de la Banque Nationale.
Dans l'architecture MVC, le contrôleur est cet adaptateur. Il est uniquement responsable du transfert des données du modèle vers la vue. Pour les visiteurs, ils ne peuvent pas voir les données réelles enregistrées dans le modèle. D'un autre point de vue, ce modèle intermédiaire peut faciliter une communication conviviale entre deux couches de données.
Grimper la fosse
Ce mode est-il vraiment si bon ? À mesure que la logique métier devient de plus en plus complexe, vous constaterez qu'il y a de plus en plus de codes dans le contrôleur et vous ne voudrez même pas ajuster et optimiser le code redondant.
Mais d'un point de vue macro, le site Web contient simplement plus de demandes, plus de formulaires, plus de pages et rien d'autre. Pourquoi ?
C'est vrai, c'est parce qu'il y a beaucoup de choses comme ceci ou cela, ce qui fait que chaque méthode dans le contrôleur est très longue, donc la solution à laquelle on peut penser est de la diviser.
Si vous avez utilisé le framework Yii, alors vous saurez que le moyen le plus simple est d'ajouter une couche de formulaire de demande. Le code est le suivant :
class AuthController { public function login() { $FLogin = new loginForm(); $FLogin->save(); } } // 一般在独立的文件夹中 class loginForm { public function __construct() { $post = $_POST; } public function save() { } }
Ce qui précède est à résoudre. le problème du formulaire dans le contrôleur. Ce problème peut fondamentalement atténuer de nombreux problèmes de codage.
Divergence
Du point de vue de la résolution de la couche de formulaire, il existe en fait de nombreux problèmes similaires qui peuvent être résolus. Nous savons qu'il existe un framework appelé vue.js sur le front-end, qui mentionne un concept appelé modèle MVVM.
En fait, lors de l'affichage de pages complexes, le backend peut également utiliser cette chose pour générer des données lors de la sortie de données vers le monde extérieur. Quant à la manière de construire un tel modèle, cela dépend de la logique métier.
Voici un exemple simple du centre utilisateur, car souvent plus d'une simple table de données est nécessaire ici :
class AuthController { public function userCenterAction() { return new userVM(); } } class userVM { public $user; public $orders; public $other; public function __construct() { $this->user = $this->getUser(); $this->orders = $this->getOrders(); $this->handle(); } private function getUser() { return NULL; } private function getOrders() { return NULL; } private function handle() { } }
Dans le code ci-dessus, il y a une couche VM qui peut obtenir les données pertinentes. Le code est placé dans leurs propres méthodes puis librement combiné dans la méthode handle. De cette façon, le code dans le contrôleur est également très simple à gérer.
Détrompez-vous, existe-t-il d'autres couches qui peuvent être encapsulées ? En fait, il y en a quelques-unes, comme la couche de requête, la couche de validation qui est souvent encapsulée par le framework, et la couche Middleware populaire dans Laravel, etc. On peut seulement dire que plus le système est complexe, plus il comporte de couches.
Derrière chaque système complexe se cachent les idées de conception d'ingénieurs de développement et d'architectes seniors. Cela dit, je ne sais pas si les lecteurs peuvent comprendre ces choses. Prenons le code ci-dessus comme exemple, il contient un autre modèle de conception : le modèle de constructeur.
Résumé
Si vous écrivez beaucoup de code, vous connaîtrez la vérité qui se cache derrière. Lorsqu'un nouveau cadre naît, l'accent passe progressivement de l'apprentissage du cadre à la manière dont le cadre est conçu et au type de problèmes qu'il résout. Où de meilleures technologies et méthodes sont utilisées, et quels peuvent en être tirés. Quelles sont les idées de design à certains endroits ? Y a-t-il de meilleurs designs ? Pourquoi puis-je y penser mais pas l'autre partie ?
J'ai utilisé divers frameworks PHP ces dernières années, allant de CI à Symfony. Sans utiliser autant de frameworks, vous ne pourrez pas expérimenter ces choses. L’apprentissage de la programmation est en fait le même que celui de l’anglais, il n’y a pas de raccourci.
Écrivez plus, réfléchissez plus, pratiquez plus...
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!