Clevere Organisationsstrukturen für PHP-Anwendungen?

Es gibt eine Million Dateisystemstrukturen, die in die Vielzahl der verfügbaren Open Source-Projekte einfließen. Dinge wie Module, Sprachdateien, Domänen, Bibliotheken von Drittanbietern, Migrationen, Internationalisierung, Backups und Syslinks zu anderen Teilen des Systems haben zu vielen Ansätzen zur Organisation des Dateisystems eines Projekts geführt.

Als PHP-Entwickler frage ich mich, ob sich bei Projekten irgendeine Art von Standardisierung abzeichnet. Mit PSR-0 haben wir endlich einen Standard zum Benennen und Laden von Dateien - aber meines Wissens über den Rest der Komponenten, aus denen das System besteht, oder darüber, wie sie auf vernünftige Weise behandelt werden können.

Wir haben es mit viel mehr als nur MVC zu tun. Welche Beispiele gibt es für große Projekte, die all diese Dinge richtig handhaben?

Es ist nicht wirklich möglich zu standardisieren, wie Projekte angelegt werden sollen, weil "es darauf ankommt".

Wenn Sie eine Standardstruktur einführen, von der jedoch einige für die zu entwickelnden Anforderungen nicht relevant sind, kann dies zu zusätzlichem Rauschen führen, das Sie nicht benötigen. Wenn die Standards für eine Vielzahl von Projekten funktionieren müssen, müssen sie ebenfalls zu viele unterschiedliche Szenarien berücksichtigen.

Unsere Aufgabe als Entwickler ist es, nach Mustern und Best Practices zu suchen und diese auf die jeweilige Aufgabe anzuwenden. Wir nutzen unsere Erfahrung und unser Fachwissen, um die richtige Dateisystemstruktur für das Projekt auszuwählen, an dem wir arbeiten.

Es scheint nicht viel Standardisierungsaufwand zu geben, und um ehrlich zu sein, sehe ich den Nutzen nicht. Es gibt nur eine Regel, die Sie einhalten sollten: Sie sollten niemals Dinge unter der Docroot haben, die nicht dorthin gehören (eine grundlegende Sicherheitsmaßnahme).

Davon abgesehen würde ich einfach das tun, was für das Projekt Sinn macht.

Wenn Sie MVC verwenden (entweder über ein Framework oder ad-hoc), ist eine Basisstruktur mit / models, / views und / controller sinnvoll. Aber selbst wenn Sie dies nicht tun, haben Sie normalerweise eine Art Datenzugriffsschicht mit Klassen, die Ihren Datenentitäten zugeordnet sind. es ist sinnvoll, ein Verzeichnis für diese zu haben; Normalerweise haben Sie auch eine Reihe von Geschäftslogikklassen und Dienstprogrammfunktionen, also ein anderes Verzeichnis für diese; Wenn Sie ein Vorlagensystem verwenden, werden Vorlagen in ein anderes Verzeichnis verschoben. und dann möchten Sie wahrscheinlich ein 'Bibliotheken'-Verzeichnis, in dem Sie alle Bibliotheken von Drittanbietern ablegen. (Sobald Sie diesen Punkt erreicht haben, machen Sie sowieso ziemlich viel MVC).

Wenn das Projekt wirklich groß ist, kann es wahrscheinlich in funktionale Submodule unterteilt werden. Wenn die Submodule ziemlich unabhängig sind, ist es sinnvoll, diese stattdessen als oberste Ebene mit einem zusätzlichen Verzeichnis für den allgemeinen Code zu verwenden.

Sie können dem Projektlayout für die beiden beliebtesten Anwendungsframeworks folgen:

1. Zend Framework - http://www.framework.zend.com/manual/en/project-structure.project.html
2. Symfony - http://symfony.com/doc/current/book/installation.html

Diese bieten eine erweiterbare Struktur, die auf Best Practices und Erfahrungen der Benutzer basiert