Yii Framework Official Guide Series 15 - Bases : meilleures pratiques MVC

Bien que Model-View-Controller (MVC) soit bien connu de presque tous les développeurs Web, comment est-il utilisé dans le développement d'applications réelles ? de MVC dérange encore beaucoup de gens. L'idée centrale derrière MC est la réutilisabilité du code et la séparation de la logique et des vues . Dans cette section, nous décrirons comment mieux utiliser MVC pour développer des applications lors de l'utilisation du framework Yii.

Pour une meilleure explication, nous supposons que l'application Web contient les sous-applications suivantes :

• Front-end : une interface de site Web publique pour les utilisateurs finaux ;

• Backend : fournit des fonctions de gestion pour gérer l'ensemble de l'application du site Web, généralement seuls les administrateurs peuvent accéder et utiliser

• Console : peut être exécutée dans une fenêtre de terminal ; Applications contenant des commandes de console ;

• API Web : fournit une interface permettant aux tiers d'interagir avec cette application.

Ces sous-applications peuvent être implémentées sous forme de modules, ou il peut s'agir d'applications Yii qui partagent du code avec d'autres sous-applications.

1. Modèles

Les modèles représentent la structure de données sous-jacente d'une application Web. Les modèles sont souvent partagés entre différentes sous-applications d'une application Web. Par exemple, un modèle LoginForm peut être. utilisé à la fois par le front-end et le back-end d'une application ; un modèle News peut être utilisé par les commandes de la console, les API Web et le front/back-end d'une application. Par conséquent, les modèles

<.>
• doit contenir des propriétés pour représenter des données spécifiques ;

• doit contenir une logique métier (par exemple, des règles de validation) pour garantir que les données représentées répondent aux exigences de conception ;

• peut contenir du code pour manipuler les données. Par exemple, un modèle

  , en plus de représenter les données d'entrée de la recherche, peut contenir une méthode SearchForm pour implémenter la recherche réelle.search

Parfois, suivre la dernière règle ci-dessus peut rendre un modèle très volumineux, contenant trop de code dans une seule classe. Cela peut également rendre le modèle difficile à maintenir si le code qu'il contient sert à des fins différentes, par exemple, un <.> le modèle peut contenir une méthode nommée  

qui n'est utilisée que par le front-end ; il peut également contenir une méthode nommée  News qui n'est utilisée que par le back-end. Cela peut convenir pour une application de petite à moyenne taille. size. Pour les applications volumineuses, la stratégie suivante peut être utilisée pour rendre les modèles plus maintenables :getLatestNewsgetDeletedNews

Définissez une classe de modèle
• qui contient uniquement du code partagé par différentes sous-applications (par exemple front). end, back end);

  NewsBase

Dans chaque sous-application, définissez un modèle
• en étendant depuis

  tout le code spécifique à la sous-application. dans ce modèle News.NewsBaseNews

Donc, si nous devions utiliser cette stratégie dans notre exemple ci-dessus, nous ajouterions un modèle

dans l'application frontale qui contient uniquement le

méthode, et nous ajouterions un autre modèle News dans l'application back-end, qui contient uniquement la méthode getLatestNews.NewsgetDeletedNewsEn général, les modèles ne doivent pas contenir de logique qui traite directement avec les utilisateurs finaux. Plus précisément, les modèles

ne doivent pas utiliser
• ,

  ou d'autres variables similaires directement liées à la demande de l'utilisateur final. N'oubliez pas qu'un modèle peut être utilisé par. une sous-application totalement différente (par exemple test unitaire, API Web) qui ne peut pas utiliser ces variables pour représenter les demandes des utilisateurs. Ces variables relatives à la demande de l'utilisateur doivent être gérées par le contrôleur.$_GET$_POST

  doit éviter d'intégrer du HTML ou un autre code de présentation. Étant donné que le code de présentation varie en fonction des besoins de l'utilisateur final (par exemple, le front-end et le back-end peuvent afficher le détail d'une actualité dans des formats complètement différents), il est mieux pris en charge par les vues.

• 2. Vues

Les vues sont chargées de présenter les modèles dans le format souhaité par les utilisateurs finaux. En général, les vues

devraient. contiennent principalement du code de présentation, tel que HTML, et du code PHP simple pour parcourir, formater et restituer les données ;

• devrait éviter de contenir du code qui effectue des requêtes de base de données explicites. Un tel code est mieux placé dans les modèles. .

• doit éviter l'accès direct à
,
• ou à d'autres variables similaires qui représentent la demande de l'utilisateur final. C'est le travail du contrôleur. affichage et disposition des données qui lui sont fournies par le contrôleur et/ou le modèle, mais sans tenter d'accéder directement aux variables de la demande ou à la base de données.

• peut accéder directement aux propriétés et méthodes des contrôleurs et des modèles. Toutefois, cela ne doit être fait qu'à des fins de présentation.

Les vues peuvent être réutilisées de différentes manières :

• Mise en page : zones de présentation communes (par exemple, en-tête de page, pied de page) peuvent être placés dans une vue de mise en page.

• Vues partielles : utilisez des vues partielles (vues qui ne sont pas décorées par des mises en page) pour réutiliser des fragments de code de présentation. Par exemple, nous utilisons _form.php la vue partielle pour afficher le formulaire de saisie du modèle qui est utilisé à la fois dans les pages de création et de mise à jour du modèle.

• Widgets : si beaucoup de logique est nécessaire pour présenter une vue partielle, la vue partielle peut être transformée en un widget dont le fichier de classe est le meilleur endroit pour contenir cette logique. Pour les widgets qui génèrent beaucoup de balisage HTML, il est préférable d'utiliser des fichiers de vue spécifiques au widget pour contenir le balisage.

• Classes d'assistance : dans les vues, nous avons souvent besoin de quelques extraits de code pour effectuez de petites tâches telles que le formatage des données ou la génération de balises HTML. Plutôt que de placer ce code directement dans les fichiers de vue, une meilleure approche consiste à placer tous ces extraits de code dans une classe d'assistance de vue. Ensuite, utilisez simplement la classe d'assistance dans vos fichiers de vue. Yii fournit un exemple de cette approche. Yii dispose d'une puissante classe d'assistance CHtml qui peut produire du code HTML couramment utilisé. Les classes d'assistance peuvent être placées dans un répertoire téléchargeable automatiquement afin qu'elles puissent être utilisées sans inclusion explicite de classe.

3. 控制器

Les contrôleurs sont le ciment qui lie les modèles, les vues et les autres composants dans une application exécutable. Les contrôleurs sont chargés de traiter directement les demandes des utilisateurs finaux. Par conséquent, les contrôleurs

• peuvent accéder à $_GET, $_POST et à d'autres variables PHP qui représentent les demandes des utilisateurs ;

• peuvent créer des instances de modèle et gérer leurs cycles de vie. Par exemple, dans une action typique de mise à jour de modèle, le contrôleur peut d'abord créer l'instance de modèle ; puis remplissez le modèle avec l'entrée utilisateur de$_POST ; après avoir enregistré le modèle avec succès, le contrôleur peut rediriger le navigateur de l'utilisateur vers la page de détails du modèle. Notez que l'implémentation réelle de l'enregistrement d'un modèle doit être située dans le modèle plutôt que dans le contrôleur.

• doit éviter de contenir des instructions SQL intégrées, qui sont mieux conservées dans les modèles.

• doit éviter de contenir du HTML ou tout autre balisage de présentation. Ceci est mieux conservé dans les vues.

Dans une application MVC bien conçue, les contrôleurs sont souvent très minces, ne contenant probablement que quelques dizaines de lignes de code ; tandis que les modèles sont très volumineux, contenant la majeure partie du code responsable de la représentation et de la manipulation des données. En effet, la structure des données et la logique métier représentées par les modèles sont généralement très spécifiques à une application particulière et doivent être fortement personnalisées pour répondre aux exigences spécifiques de l'application ; tandis que la logique du contrôleur suit souvent un modèle similaire dans toutes les applications et peut donc être simplifiée par le cadre sous-jacent ou les classes de base. ，更多相关内容请关注PHP中文网（www.php.cn）！