Structure de répertoire pour MVC

Je suis en train de nettoyer le cadre que j'ai travaillé. Dès maintenant, le site se compose de l'un des répertoires suivants:

Models
Views
Controllers
Helpers (Miscellaneous functions)
Libraries (Universal classes, like library and session management)
Images
Style

Toutes les fois qu'une page est appelée, le routeur script recherche le contrôleur associé, de sorte thesite.com/login serait instancier Login_Controller à '/controllers/login.php " Le problème que je me pose est, le routeur script lui-même se sent comme un type de contrôleur, comme le fait view.php qui gère les données de mise en forme pour être manipulé par la vue appropriée. Mais ce ne sont pas tout à fait comme la page des contrôleurs, car ils contrôlent le MVC lui-même. Je suis encore un peu nouveau pour cette architecture, et je suis curieux de voir comment quelqu'un avec plus d'expérience, d'organiser cela.

Je pourrais classer le routeur et de la vue des contrôleurs de bibliothèques, ou serait-il mieux de créer un sous-répertoire dans /contrôleurs appelés "pages", ou d'autres idées? Merci beaucoup.

source d'informationauteur dlwiest | 2011-10-31

  1. 8

    Je vous propose de suivre le Symfony 1.x structure de répertoire. Clair, logique, sécurisé.

    Extrait du livre "The definitive guide to Symfony" par Fabien Potencier & François Zaninotto :

    apps/
  frontend/
  backend/
cache/
config/
data/
  sql/
doc/
lib/
  model/
log/
plugins/
test/
  bootstrap/
  unit/
  functional/
web/
  css/
  images/
  js/
  uploads/
    • apps/ Contient un répertoire pour chaque application du projet (en général, frontend
      et backend pour le front et back office).
    • cache/ Contient la version en cache de la configuration, et (si vous l'activez) le
      cache version des actions et des modèles du projet. Le mécanisme de cache
      (détaillée dans le Chapitre 12) utilise ces fichiers pour accélérer la réponse aux requêtes web.
      Chaque application aura un sous-répertoire, contenant prétraitées PHP
      et les fichiers HTML.
    • config/ Détient la configuration générale du projet.
    • de données/ Ici, vous pouvez stocker les fichiers de données du projet, comme un schéma de base de données, SQL
      fichier qui crée des tables, ou même une base de données SQLite fichier.
    • doc/ Magasins de la documentation du projet, y compris vos propres documents et les
      la documentation générée par PHPdoc.
    • lib/ Dédié à l'étranger les classes ou les bibliothèques. Ici, vous pouvez ajouter le code qui doit
      pour être partagé entre vos applications. Le modèle/ sous-répertoire stocke les
      modèle d'objet du projet (décrit dans le Chapitre 8).

      • log/ Magasins applicables fichiers journaux générés directement par symfony. Il peut aussi contenir des
        fichiers journaux de serveur web, base de données des fichiers journaux ou les fichiers journaux à partir de toute partie du projet.
        Symfony crée un fichier journal par application et par l'environnement (les fichiers journaux sont
        discuté dans le Chapitre 16).
    • plugins/ Stocke les plugins installés dans l'application (les plugins sont discutés dans le Chapitre
      17).
    • test/ Contient unitaires et tests fonctionnels écrit en PHP et compatible avec la
      symfony framework de test (voir le Chapitre 15). Lors de la configuration du projet,
      symfony ajoute automatiquement certaines talons avec quelques tests de base.
    • web/ La racine du serveur web. Les seuls fichiers accessibles à partir d'Internet sont les
      ceux situés dans ce répertoire.
  2. 18

    Je vous suggère d'étudier un cadre de la structure de répertoire, comme symfony2 ou yii

    voici ce que j'ai choisi pour le mien:

    public_html/              (for public files) (should be public, place only index.php in here)
public_html/css/
public_html/images
public_html/js            (for your js files, or custom generated ones)
lib/                      (for my libs)  (should be private)
lib/vendor/               (for 3rd party libs)
application/              (for the whole app) (should be private)
application/class         (classes that make the app work such as mainApp, Controller, Model, View, etc...)
application/class/model   (all the models)
application/class/view    (all the views)
application/class/view/html (templates used by the views)
application/class/controller (all controllers)
application/class/helper  (helper functions)
application/class/lib     (libs that you develop for the application)
application/template      (layout and/or templates for the application)
application/conf          (config files)
application/log           (log files)
application/cron          (scheduled jobs)
application/database      (for database migration scripts)
...

    Vous pouvez également utiliser les conventions de nommage de fichiers, tels que: YourClassName.class.php pour les clases, YourView.phtml vos points de vue, etc. Vérifier un cadre et vous apprendrez comment structurer joliment et app.

  3. 6

    Je ne voudrais pas me considérer comme un expert, mais une solution serait de déplacer votre "cadre" de la mise en œuvre. Ce que je veux dire, c'est de déplacer votre 'routeur', 'view.php" et les autres classes du framework pour certains emplacement externe qui permet ensuite de les inclure dans votre index.php ou quel que soit le fichier de votre point d'accès.

    Alors seulement le contenu serait dans votre répertoire de l'application, tandis que tous les fichiers du framework serait dans un endroit qui n'est pas accessible via le serveur web.

    Juste une idée 🙂