Cet article explore une structure de répertoires optimisée pour les projets développés avec le framework Yii, particulièrement adaptée aux équipes et aux projets de taille moyenne à grande. Bien que toute structure puisse être ajustée à des besoins spécifiques, celle-ci offre une base solide pour une gestion efficace du code et une collaboration fluide.

Organisation Générale du Projet

L'architecture proposée vise à compartimenter les différentes facettes d'une application complexe. Voici un aperçu de la hiérarchie des fichiers :

/
    backend/             # Application pour l'administration
    common/              # Ressources partagées entre les applications
        components/      # Composants génériques (aides, widgets)
        config/          # Configurations partagées
            params.php
            params-local.php *
        lib/             # Bibliothèques tierces communes
            Pear/
            yii/
            Zend/
        migrations/      # Scripts de migration de base de données
        models/          # Modèles ActiveRecord partagés
            Comment.php
            Extension.php
            ...
    console/             # Application console pour les tâches en arrière-plan
        commands/        # Classes de commandes console
            SitemapCommand.php
            ...
        config/          # Configurations spécifiques à la console
            main.php
            main-local.php *
            params.php
            params-local.php *
        runtime/         # Fichiers générés temporairement par la console
        yiic.php *       # Script d'entrée pour la console (local)
    frontend/            # Application principale pour les utilisateurs finaux
        components/      # Composants spécifiques au frontend
        config/          # Configurations spécifiques au frontend
            main.php
            main-local.php *
            params.php
            params-local.php *
        controllers/     # Contrôleurs de l'interface utilisateur
            SiteController.php
            ...
        lib/             # Bibliothèques tierces spécifiques au frontend
        models/          # Modèles spécifiques au frontend
            ContactForm.php
            SearchForm.php
        runtime/         # Fichiers générés temporairement par le frontend
        views/           # Vues des actions des contrôleurs
            layouts/
            site/
        www/             # Répertoire public (racine web) du frontend
            assets/
            css/
            js/
            index.php *  # Script d'entrée principal (local)
    yiic                   # Exécutable Yii pour la console (global)
    yiic.bat               # Exécutable Yii pour Windows (global)

Dans un contexte de développement collaboratif, un système de contrôle de version (tel que Git ou SVN) est utilisé pour gérer cette structure. Les fichiers marqués d'un astérisque (*) ne sont généralement pas inclus dans le contrôle de version, comme nous l'expliquerons plus loin.

Répertoires de Premier Niveau

Au niveau le plus élevé, nous distinguons quatre répertoires principaux, chacun ayant un rôle bien défini :

• backend : L'application d'administration, dédiée aux tâches de gestion et de maintenance du système par les administrateurs.
• frontend : L'application front-end, qui présente l'interface principale aux utilisateurs finaux de la plateforme.
• console : L'application console, regroupant les scripts et commandes nécessaires pour les traitements en ligne de commande ou les tâches planifiées.
• common : Le répertoire commun, contenant toutes les ressources partagées entre les applications mentionnées ci-dessus.

Cette segmentation permet une isolation claire des préoccupations et facilite l'ajout de nouvelles applications si les besoins évoluent (par exemple, une application api pour des services web).

Structure des Applications Individuelles

Chaque application (backend, frontend) possède une structure interne similaire, favorisant la cohérence. On y retrouve généralement :

• components : Contient les composants (classes utilitaires, helpers, widgets) exclusifs à cette application.
• config : Héberge les fichiers de configuration spécifiques à l'application.
• controllers : Abrite les classes de contrôleurs.
• lib : Dédie aux bibliothèques tierces utilisées uniquement par cette application.
• models : Contient les classes de modèles propres à l'application.
• runtime : Sert de zone de stockage pour les fichiers générés dynamiquement (cache, logs).
• views : Stocke les scripts de vue associés aux actions des contrôleurs.
• www : Le répertoire racine web de l'application, accessible publiquement.

L'application console diffère légèrement en l'absence de controllers, views et www, mais elle inclut un répertoire commands pour ses classes de commandes spécifiques.

Le Répertoire common

Le répertoire common est le pilier de la réutilisabilité du code. Il centralise les fichiers et les ressources qui sont partagés par plusieurs, voire toutes, les applications. Par exemple, les modèles ActiveRecord qui interagissent avec la base de données peuvent être placés dans common/models, évitant ainsi leur duplication. De même, les helpers ou les widgets utilisés dans plusieurs contextes trouvent leur place dans common/components.

Sa propre structure interne reflète celle d'une application typique (components, models, lib, config) pour une meilleure organisation. Les configurations partagées, comme les paramètres de connexion à la base de données, sont logiquement stockées sous common/config. De plus, pour gérer l'évolution du schéma de la base de données, les scripts de migration sont conservés dans common/migrations, offrant un suivi centralisé des modifications structurelles.

Gestion des Configurations d'Application

Les applications d'un même système partagent souvent des paramètres communs, tels que les identifiants de base de données ou des variables globales. Pour éviter la redondance et simplifier la maintenance, ces configurations partagées sont extraites et stockées de manière centralisée, typiquement dans common/config.

Dans un environnement d'équipe, il est courant que chaque développeur ait des configurations locales distinctes (chemins d'accès, bases de données de développement). Pour gérer ces variations sans conflit, nous séparons les configurations en deux catégories :

• Configuration de base (main.php, params.php) : Ces fichiers contiennent les paramètres généraux et devraient être sous contrôle de version pour être partagés par tous.
• Configuraton locale (main-local.php, params-local.php) : Ces fichiers contiennent les ajustements spécifiques à l'environnement de chaque développeur. Ils ne doivent PAS être versionnés.

Au démarrage de l'application, le script d'entrée (index.php) fusionne ces deux ensembles de configurations. La configuration locale surcharge et complète la configuration de base, garantissant que chaque environnement fonctionne avec ses propres réglages tout en héritant des paramètres globaux.

<?php
// Inclure le fichier d'initialisation du framework Yii
require_once(__DIR__ . '/chemin/vers/yii.php');

// Charger les configurations spécifiques à l'environnement local
$configurationLocale = require(__DIR__ . '/chemin/vers/config/main-local.php');

// Charger la configuration de base de l'application
$configurationDeBase = require(__DIR__ . '/chemin/vers/config/main.php');

// Fusionner les configurations : la configuration locale prévaut sur la base
$parametresApplication = CMap::mergeArray($configurationDeBase, $configurationLocale);

// Créer et exécuter l'instance de l'application Yii
Yii::createApplication($parametresApplication)->run();

Alias de Chemin

Pour simplifier les références aux fichiers et classes à travers les différentes applications, un alias de chemin racine, nommé site, est généralement défini. Cet alias pointe vers le répertoire parent qui contient les quatre répertoires de premier niveau (backend, frontend, console, common). Ainsi, il devient possible de référencer une classe comme site.frontend.models.ContactForm, ce qui améliore la lisibilité et la maintenance du code.

Processus de Déploiement

Le déploiement en production, ou même entre différents environnements de développement, peut être géré efficacement via le système de contrôle de version. Plutôt que d'utiliser des outils de transfert de fichiers (FTP), le serveur de production peut être considéré comme un environnement de développement spécialisé. Une copie initiale du projet est extraite du système de contrôle de version vers l'emplacement désiré sur le serveur, ou une copie existante est mise à jour.

Suite à cela, des configurations locales spécifiques à l'environnement de production sont créées ou ajustées. Cela peut inclure la modification des paramètres de connexion à la base de données ou la désactivation du mode de débogage (par exemple, en définissant YII_DEBUG à false dans index.php). La séparation des applications en répertoires distincts offre également la flexibilité de les déployer sur des serveurs différents si la scalabilité l'exige.