2015-07-14 2 views
10

Ich versuche, die Verzeichnisstruktur für eine PHP-Website herauszufinden.Verzeichnisstruktur für eine PHP-Website mit Composer, Schluck und Travis

Die Website wird verwenden:

  • einen sehr einfache PHP MVC-Framework (nämlich MinimalMVC, aber ich bin für eine generische Lösung suchen, so kann der Rahmen wahrscheinlich ignoriert werden)
  • Komponisten zu verwalten PHP-Abhängigkeiten
  • SCSS für Styling
  • schluck die SCSS (für die dev build) zu kompilieren und zu auch minify und verketten JS und CSS-Ausgang sowie minify Bilder etc. (nur für den Einsatz Build)
  • Travis CI für CI Sachen

So nach viel Denken und Planung und Blick auf Problemen mit verschiedenen Arten von Verzeichnisstrukturen, die ich kam mit, ich kann immer noch nicht etwas finden, das meine Kriterien erfüllt:

  • gulp deploy sollte in der Lage sein, einen Bereitstellungsordner zu erzeugen, die, wenn sie in ein /var/www/html/ Verzeichnis auf einem Server Apache setzen, Just TM

    arbeiten sollte

    Hinweis: MinimalMVC (und auch CodeIgniter und andere ähnliche Frameworks) benötigen, um ihre index.php Datei in das Root-Verzeichnis, mit einem app und sys Ordner im selben Verzeichnis

  • Seit PHP wird von der Build nie wirklich verarbeitet Prozess, wäre es toll, wenn unnötige Kopie der src/**/*.php Dateien in etwas wie build/**/*.php vermeidbar wäre. Im Grunde behält der PHP-Teil keinen Schluck, ich würde es vorziehen, ihn nicht durch Schluck zu beeinflussen.

Nun, meine Gedanken sind ein bisschen ein Durcheinander, weil ich zu viel darüber nachzudenken habe, so verzeihen Sie mir diese Frage auch ein bisschen ein Durcheinander zu sein, aber die grundlegende Frage ist, wie sollte die Verzeichnisstruktur aussehen?

Eine Idee:

. 
|-- composer.json 
|-- gulpfile.js 
|-- package.json 
|-- src 
| |-- app 
| | |-- controllers 
| | |-- models 
| | `-- <other_framework_stuff> 
| |-- assets 
| | |-- css 
| | |-- img 
| | |-- js 
| | `-- raw 
| |  `-- scss 
| |-- index.php 
| `-- sys 
|  `-- <framework_stuff> 
|-- test 
`-- vendor 
    `-- <composer_stuff> 

In dieser Struktur arbeiten die Entwickler nur im /src Verzeichnis. Der SCSS wird von /src/assets/raw/scss/ zu src/assets/css kompiliert. Auf diese Weise bleibt das PHP aus dem Build-Prozess entfernt. Beim Versuch, ein Verzeichnis deploy zu erzeugen, wird der Ordner src kopiert, das Verzeichnis /src/assets/raw/ (also kein /build/assets/raw) existiert nicht, und das produktions-/deployment-fähige CSS, JS und Bilder befinden sich in /build/assets/.

Das erste Problem mit dieser Lösung ist das seltsame Verzeichnis src/assets/raw, das imho hässlich scheint. Das zweite Problem ist das Verzeichnis /vendor. Dies bedeutet, dass das PHP auf Zeug von außerhalb src verweist. Wenn /src/index.php sich darum kümmert, würde es ../vendor/autoload.php einschließen. Dann würde das bedeuten, dass der gleiche Code in /build/index.php kopiert wird.Und dann /build/ wird nicht ausgeführt, indem Sie einfach in /var/www/html fallen, es sei denn, vendor ist in /var/www, die nur seltsam scheint.

Es gibt viele andere Sachen, an die ich gedacht habe, aber alles scheint auf die eine oder andere Weise hässlich zu sein. Um diese Frage nicht zu lange zu machen, höre ich hier auf.

Hilfe, bitte. Sollte ich einfach vendor in /src/ mit vendor-dir in composer.json setzen? (Ich weiß, Ew.) Welche Art von Verzeichnisstruktur sollte ich verwenden?

+4

Sie sollten sich von bestehenden Frameworks inspirieren lassen, zum Beispiel verwendet Laravel eine Struktur, die ziemlich nah an dem ist, was Sie tun: http://laravelbook.com/laravel-architecture/ BTW, wenn Sie können, würde ich nicht empfehlen Sie haben den Herstellerordner in Ihrem Build-Verzeichnis und führen stattdessen 'composer install' auf Ihrem Produktionsserver aus. – Korri

+0

@Korri, danke, das hat geholfen. –

+2

Stimmen Sie dem Kommentar von @ Korri zu. Solange Sie Ihre composer.lock-Datei festschreiben, sollte 'composer install' nicht lange dauern, wenn Sie sie bereitstellen. Nicht direkt mit Ihrer Frage verbunden, aber die wichtigste Sache, die ich ändern würde, würde trennen, was tatsächlich statisch vom Webserver abgerufen wird 'src'. Das schützt Sie vor Benutzern, die versuchen, direkt auf PHP-Dateien zuzugreifen, wo viele Sicherheitsprobleme auftreten. Der Webserver wäre so konfiguriert, dass er auf ein 'public'-Verzeichnis als Dokumenten-Root zugreift. Die meisten Frameworks folgen dieser Art der Einrichtung. –

Antwort

5

Ich stimme dem Kommentar von Korri oben zu, in dem Sie davon profitieren könnten, sich von bestehenden Frameworks inspirieren zu lassen.

Persönlich fühlt sich diese Art von Verzeichnisstruktur für mich richtig an.

. 
|-- composer.json 
|-- gulpfile.js 
|-- package.json 
|-- changelog.md 
|-- readme.md 
|-- /src (This is the API code that *I'm* responsible for, and that I *own*.). 
| |-- /app 
| | |-- /controllers 
| | |-- /models 
| | `-- <other_framework_stuff> 
| /public (Keeping this outside of the src dir, means that you can give this to your front-end devs without needing to have the entire codebase). 
| | |-- /styles 
| | |-- /images 
| | |-- /js 
| /config (Put all configuration files outside of the src scope, so you can keep it outside of source control) 
| /build (CI build related configuration) 
| | |--phpcs.xml 
| | |--phpdocx.xml 
|-- /tests (separating out your tests in this way can help you run tests separately, more easily) 
| | |--acceptance 
| | |--integration 
| | |--unit 
|-- /vendor (Depenedencies installed via Composer) 

Wirklich, es gibt keine Community getrieben richtige Antwort auf Ihre Frage. Die richtige Antwort ist spezifisch für Ihre Geschäft, das Team Sie arbeiten in, und das Projekt selbst.

Ich würde nie das /vendor Verzeichnis im /src Verzeichnis setzen - weil Sie nicht eigenen es. Sie sind nicht für die Änderungen am Code innerhalb der Abhängigkeiten Ihres Projekts verantwortlich, sodass Sie in einem eigenen Bereich außerhalb der Projektgrenzen bleiben sollten.

Mit Autoloading PSR-4 ist es wirklich nicht so wichtig, über Ihre Verzeichnisstruktur, es kann jederzeit leicht geändert werden, ohne Auswirkungen auf Ihren Code. Also, experimentieren Sie und sehen Sie, was fühlt sich für Sie richtig an.