Optimale Dateisystemstruktur für Skriptsprache MVC-Anwendungen

Question

Wenn ich von Skriptsprachen spreche spreche ich von Sprachen wie Python, Perl und (in meinem Fall) PHP. Nach der Verwendung von CodeIgniter, Zend und vielen anderen unterhaltsamen MVC-Systemen scheint es klar zu sein, dass eine Sache, auf die man sich einigen kann, die Ordnerstruktur ist (zusammen mit anderen Dingen, die so ähnlich sind). Das ist wirklich ein Problem für mich, weil ich keine gute Dokumentation über die Vorteile verschiedener Strukturdesigns finden kann. Die meisten Leute empfehlen nur eine, weil das ist, was sie verwenden ohne Rücksicht auf Verbesserungen im Design.

Eines der Dinge, die ich hoffe, dass wir uns einig sind, ist, dass das Überprüfen des Dateisystems auf vorhandene Dateien beim Autoloading von Klassen sehr schlecht ist. Unsere Klassen sollten sich nicht an einer von fünf möglichen Stellen befinden, was zu einer Flut von file_exists() Prüfungen für jede geladene Bibliothek führt.

Wie auch immer, ich versuche, Verzeichnisstrukturen zu sammeln, die ich vergleichen kann, die besten Praktiken zu finden, wenn für Anwendungen, die Planung:

1. sind OOP basiert, welche höchstwahrscheinlich bedeutet MVC
2. sind international in Rahmen und Unterstützung Sprachdateien/Übersetzungen
3. sind offen für Module/Plugins, so dass komplette Pakete in unsere Codebasis fallen gelassen werden
4. klar definieren, was los ist und wo sie suchen müssen für bestimmte Klassen
5. Mögliche Unterstützung für mehrere Standorte aus der gleichen Struktur ausgeführt wird (siehe/site Verzeichnisse unten)

Also hier ist, was ich bisher haben. Denken Sie daran, dass libs nur ein Begriff ist, der Ihr Hauptbibliotheks-/Klassenverzeichnis bedeutet und je nach Ordnerstruktur sogar Modelle enthalten kann. Außerdem habe ich jegliche Art von statischem Inhalt (JS/CSS/Bilder) ausgeschlossen, da dieses Zeug wirklich ein Nachdenken ist und nicht mit unserem serverseitigen Code zusammenhängt - es könnte sogar auf einem anderen Server sein! Das Gleiche gilt für Caches, Datei-Uploads, lang und alle anderen generierten Inhalte.

/controllers 
/views 
/models 
/libs 
/config 
index.php 

Diese Art von erinnert mich an das Zend Framework, das alles in einem einzigen Ordner Libs häuft (die auch Unterordner enthält Dinge organisiert zu halten). Funktioniert nur für eine einzelne Site.

---

/libs 
/site 
    /controllers 
    /views 
    /models 
    /config 
index.php 

Dies würde eine Multi-Site-Version der obigen Struktur.

---

/libs 
/functions 
/site 
    /controllers 
    /models 
    /views 
    /config 
/site2 
    /controllers 
    /models 
    /views 
    /config 
/modules 
    /user 
     /controllers 
     /models 
     /views 
index.php 

Dies würde Version, die mehrere Standorte und Drop in Module ermöglichen würde. Die Module wären eigenständige MVC-Apps wie ein Forum, das Geschäftslogik, CRUD und Ansichten beinhalten würde.

Also hat jemand eine perfekte Struktur sie könnten teilen oder führen Sie mich bei der Auswahl einer guten erweiterbaren Design?

Answer 1

Hier ist ein zu komplexes Beispiel, das alles gut organisiert - auf Kosten von Klarheit und Einfachheit.

alt text http://www.gsdesign.ro/blog/wp-content/uploads/2008/12/zend-framework-modular-dire.png

Answer 2

Nicht speziell symfony, empfehlen, sondern Ansatz ist es, was ich denke, ist pretty good (aber nicht "perfekt")

für Ermöglicht:

• L18N
• Multiple Umgebungen (dev, qa, prod usw.)
• Externe Bibliotheken
• Plugins
• Mehrere Standorte (Domänen oder auf andere Weise)
• Stapelverarbeitung (Befehlszeilenaufgaben)
• Unit-Tests
• Dokumentation
• Logging
• Caching

Auch Unter Symfony's Höhen und Tiefen ist eine Sache, die ich ziemlich gut finde, Caching. Und ich meine nicht template/view caching - ich meine compilation-like caching.

Wenn ein Projekt das erste Mal ausgeführt wird, erstellt Symfony eine Masterdatei von Bibliotheksklassen, die bei aufeinanderfolgenden Zugriffen auf die Anwendung nicht nur Dutzende oder sogar Hunderte von Statusaufrufen pro Anforderung entfernt, sondern auch andere Optimierungen wie das Entfernen durchführt von Kommentaren.

Es speichert auch Konfigurationsdaten und Autoload-Informationen, die alle an Ihre Bedürfnisse angepasst werden können.

Answer 3

Wir verwenden eine Struktur ähnlich wie Ihre letzte "Multi-Site" -Option für eine Multi-Site-Forum-Engine, die wir im Haus erstellt haben und es funktioniert wirklich gut. Sie können immer Module kopieren, wenn Sie benötigen, und es ermöglicht auch die Möglichkeit von Site A ihr Modul ein wenig anzupassen, ohne Site B zu beeinträchtigen.

Wenn Sie in praktische Anwendungen davon kommen, sprechen Sie über völlig getrennt Teams, vielleicht sogar Unternehmen, die diese beiden Seiten nutzen, ist eine kleine Trennung nicht das Schlimmste. Wir haben auch einen freigegebenen Modulordner, aber wenn Sie eine Datei im Ordner Module der Site gleich nennen, wird stattdessen diese Version verwendet. Mit diesem und __autoload (vorausgesetzt PHP) müssen sich die Site-Entwickler nicht wirklich darum kümmern, wo sich das Modul befindet, um es zu benutzen.