Principes de répartition des responsabilités dans l'architecture MVC

J'étais récemment responsable d'un projet qui utilisait le framework MVC du Yii Framework. Au début, je pensais que la structure était très robuste.

Mais à mesure que nous approfondissions notre compréhension de la logique métier, nous avons commencé à prendre conscience de la gravité du problème.

J'ai mal compris le contrôleur dans MVC et j'ai pris pour acquis que toute la logique métier était implémentée dans l'action du contrôleur sur la base de l'expérience passée.

En conséquence, chaque contrôleur possède des milliers de lignes de code, qui deviennent de plus en plus volumineuses.

Finalement, j'ai décidé de refactoriser le code. L'origine était la nécessité d'une interface API ouverte.

Selon l'architecture actuelle, le code est fondamentalement impossible à réutiliser. Je dois écrire de nombreuses fonctions encore et encore, ce qui est vraiment inacceptable.

La programmation orientée objet n'est pas qu'un terme utilisé dans les manuels scolaires !

Ce n'est que lorsque j'ai commencé à pratiquer que j'ai réalisé à quel point il est rare d'avoir une conscience orientée objet et une vision d'ensemble.

Principes de conception MVC

1 Qu'est-ce que MVC exactement

Modèle -. View-Controller (MVC) est un framework de conception (modèle de conception).

L'objectif de MVC est de séparer la logique métier des considérations d'interface utilisateur.

De cette façon, les développeurs peuvent plus facilement modifier chaque partie sans affecter les autres.

Dans MVC, le modèle représente les données et les règles métier ; la vue contient des éléments de l'interface utilisateur, tels que le texte, les formulaires, etc. ; le contrôleur gère la communication entre les modèles et les vues.

MVC est implémenté dans divers langages de programmation. Par exemple, dans le développement d'applications J2EE,

View peut être implémenté par jsp ; Controller est un servlet, désormais généralement implémenté avec Struts ; Un bean entité à implémenter.

2. Quels problèmes ai-je rencontrés

Yii Framework est un framework PHP populaire qui emprunte le concept ActiveRecord(AR) à Ruby on Rails.

Chaque table de la base de données peut utiliser la classe AR pour effectuer facilement des opérations d'ajout, de suppression, de modification et de requête.

Il traite AR comme un modèle et recommande de le placer dans un répertoire appelé models.

Ainsi, après avoir généré automatiquement l'AR correspondant au tableau, j'ai pris pour acquis que j'avais déjà le calque Modèle.

En fait, AR n'est qu'un DAO (couche d'accès aux données), pas une couche de modèle.

Presque toutes nos activités sont placées dans le contrôleur : effectuer divers jugements logiques sur les formulaires soumis par les utilisateurs, effectuer des calculs, instancier l'AR pour stocker des données...

À cause d'un contrôleur là il y aura plusieurs actions, et chaque action a un tel traitement métier.

Finalement, j'ai constaté que mon code contrôleur dépassait 1000 lignes.

Soudain, un jour, le leader a déclaré que notre système devrait ouvrir des API pour que les anciens systèmes existants puissent appeler et fournir des interfaces tierces.

Le tiers n'a qu'à donner un paramètre, et ce système ne donne qu'une valeur de résultat. Il ne se soucie pas du traitement commercial.

Le problème est que le contrôleur a déjà implémenté ces services, mais il accepte les soumissions de formulaires. Comment peut-il également accepter les documents XML SOAP ?

Le contrôleur, comme les préservatifs, doit être aussi fin que possible.

Sa responsabilité devrait uniquement être d'accepter les entrées de l'utilisateur, puis de les transmettre immédiatement à d'autres classes pour traitement.

De cette façon, le contrôleur est uniquement responsable de fournir différentes interfaces, afin que nous puissions séparer la logique métier et que les activités séparées puissent être facilement réutilisées.

Qui gérera cette partie séparée de l’entreprise ? La réponse devrait être Modèle.

3. Les responsabilités de View

La partie View est relativement claire, elle est responsable de l'affichage.

Tout ce qui n'a rien à voir avec l'interface d'affichage ne doit pas apparaître dans la vue.

Par conséquent, les déclarations de jugement complexes et les processus de calcul complexes ne devraient généralement pas apparaître dans View.

peut avoir des instructions de boucle simples et des instructions de formatage. Par exemple, la liste de textes sur la page d’accueil du blog est une sorte de boucle.

Pour les applications Web PHP, HTML est le contenu principal de View.

View ne doit jamais appeler la méthode d'écriture du modèle.

En d'autres termes, View lit uniquement les données du modèle mais ne réécrit pas le modèle.

On dit donc que Vue et Modèle sont indissociables.

De plus, $_GET et $_POST ne sont pas directement accessibles dans View et doivent être transmis à View par le contrôleur.

De plus, View n'a généralement aucune préparation pour le traitement des données, comme l'interrogation de la base de données, etc.

Ceux-ci sont généralement placés dans le contrôleur et transmis à la vue sous forme de variables.

En d'autres termes, la donnée à utiliser dans la vue est une variable.

4. Responsabilités du modèle

Pour le modèle, la chose la plus importante est de sauvegarder et de sortir les informations.

Par exemple, la classe Post doit avoir un attribut title utilisé pour enregistrer le titre d'un article de blog, et doit avoir une opération de suppression. Ce sont tous les contenus du modèle.

Les données, le comportement et les méthodes sont le contenu principal de Model.

Dans le travail réel, Model possède la plus grande quantité de code dans MVC.

Le modèle est la partie la plus complexe de la logique, car la logique métier de l'application doit également être exprimée ici.

Faites attention à distinguer le modèle du contrôleur.

Le modèle gère la logique métier et le contrôleur coordonne simplement la relation entre le modèle et la vue.

Tant qu'il est lié au business, il doit être placé dans le Modèle.

La vérification des données, les constantes publiques et les variables doivent toutes être placées dans la couche modèle

En d'autres termes, les attributs ou méthodes pouvant être réutilisés doivent être placés dans la couche modèle, une fois définis. utilisé partout.

Le modèle ne doit pas accéder aux données de demande, de session et autres données d'environnement, celles-ci doivent être injectées par le contrôleur.

Un bon design doit être un gros modèle et un contrôleur fin.

5. Responsabilités du contrôleur

Pour le contrôleur, il répond principalement aux demandes des utilisateurs, décide quelle vue utiliser et quelles données doivent être préparées pour l'affichage.

Par conséquent, le code d'accès à la requête doit être placé dans le contrôleur, tel que $_GET, $_POST, etc.

Le contrôleur doit se limiter à l'obtention des données de demande de l'utilisateur et ne doit effectuer aucune opération ni prétraitement sur les données. Ceux-ci doivent être placés à l'intérieur du modèle.

Pour les opérations d'écriture de données, il est nécessaire d'appeler la méthode de la classe Model pour terminer.

En réponse aux demandes des utilisateurs, le rendu de la vue est appelé.

De plus, il ne devrait généralement y avoir aucun code HTML ou autre élément de la couche de présentation, cela devrait être le contenu de la vue.

6. Lumières

Il y a ce paragraphe dans la documentation officielle de Yii Framework :

In a well-designed MVC application, controllers are often very thin, containing probably only a few dozen lines of code; while models are very fat, containing most of the code responsible for representing and manipulating the data.

En bref, Rich Model is Better.

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!