Directory-Struktur für eine PHP-website mit Komponisten, schlucken und Travis

Ich versuche, herauszufinden, die Verzeichnis-Struktur für eine php-website.

Die website verwenden:

  • eine sehr einfache php-MVC-framework (nämlich MinimalMVC, aber ich bin auf der Suche nach einer generischen Lösung, so dass die Rahmen können wahrscheinlich ignoriert werden)
  • composer zum verwalten von PHP-Abhängigkeiten
  • SCSS für styling
  • Schluck zum kompilieren der SCSS (für die dev-build) und auch verkleinern und verketten von JS-und CSS-Ausgabe sowie verkleinern der Bilder, etc. (nur für die Bereitstellung bauen)
  • Travis CI für CI Zeug

So, nach viel nachdenken und planen und auf der Suche nach Fragen mit unterschiedlichen Arten von Verzeichnis-Strukturen, die ich kam mit, kann ich immer noch nicht etwas finden, das erfüllt meine Kriterien:

  • gulp deploy sollte in der Lage sein zum generieren eines deployment-Ordner, die, wenn Sie in einer /var/www/html/ Verzeichnis auf einem Apache-server, sollte Nur ArbeitenTM

    Hinweis: MinimalMVC (und auch CodeIgniter und anderen ähnlichen frameworks) benötigen, die Ihre index.php - Datei in das root-Verzeichnis, mit einem app und sys Ordner im gleichen Verzeichnis

  • Da der PHP-ist nie wirklich verarbeitet, indem Sie den build-Prozess, es wäre toll, wenn unnötiges kopieren der src/**/*.php Dateien in so etwas wie build/**/*.php vermeidbar war. Im Grunde, der PHP-Teil nicht schlucken, würde ich es vorziehen, es bleibt unberührt von gulp.

Nun, meine Gedanken sind ein wenig Durcheinander, weil ich mir überlegt habe dieses zu viel, so verzeihen Sie mir für diese Frage ein bisschen chaotisch zu, 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, die Entwickler arbeiten nur innerhalb der /src - Verzeichnis. Die SCSS wird zusammengestellt aus /src/assets/raw/scss/ zu src/assets/css. Dieser Weg, der PHP bleibt entfernt von der build-Prozess. Wenn Sie versuchen, zu generieren deploy Verzeichnis, den src-Ordner kopiert, die /src/assets/raw/ (also keine /build/assets/raw) Verzeichnis existiert nicht, und die Produktion/Bereitstellung CSS, JS und Bilder finden sich in /build/assets/.

Das erste problem mit dieser Lösung ist die seltsame src/assets/raw - Verzeichnis, das scheint hässlich imho. Das zweite problem ist die /vendor - Verzeichnis. Dies bedeutet, dass die php-Referenzen, Sachen von außerhalb src. Also, wenn /src/index.php kümmert sich um es, es ../vendor/autoload.php. Dann würde das bedeuten, dass der gleiche code ist, kopiert wird in /build/index.php. Und dann /build/ laufen nicht nur fallenlassen es in /var/www/html, es sei denn vendor ist in /var/www die scheint nur seltsam.

Es gibt eine Menge von anderen Sachen die ich gedacht habe, aber alle scheint es hässlich irgendeiner Weise oder die andere. Um zu vermeiden, dass diese Frage zu lang ist, werde ich hier aufhören.

Helfen, bitte. Sollte ich einfach vendor in /src/ mit vendor-dir im composer.json? (Ich weiß, eww.) Welche Art von Verzeichnis-Struktur sollte ich verwenden?

  • Nehmen Sie inspiration aus bereits bestehenden frameworks, z.B. Laravel nutzt eine Struktur, die ziemlich nahe an dem, was Sie tun: laravelbook.com/laravel-architecture BTW, wenn du kannst, würde ich empfehlen, nicht mit der vendor-Ordner im build-Verzeichnis und läuft composer install in Ihre Produktions-server statt.
  • danke, das hat geholfen.
  • Stimme dem @Korri Kommentar. Solange Sie verpflichten sich, Ihre Komponisten.lock-Datei, composer install sollte nicht lange dauern, wenn Sie bereitstellen.Nicht direkt bezogen auf deine Frage, aber die wichtigste Sache, die ich ändern würde, wäre die Trennung, was wird tatsächlich zugegriffen statisch vom Webserver aus src. Schützen Sie Benutzer aus, die versuchen direkt Zugriff auf php-Dateien, wo viele Sicherheitsprobleme passieren. Der web-server konfiguriert werden, um Zugriff auf eine public Verzeichnis als document root. Die meisten frameworks Folgen, die Möglichkeit der Einrichtung.
  • Normalerweise habe ich eine boilerplate - Verzeichnis in die root meiner app, die enthält Entwicklungs-Vermögenswerte, wie less, javascripts, bower.json, packages.json, fonts, images, und dann habe ich entweder grunt oder gulp zu verarbeiten und senden Sie Sie an dist/ - Verzeichnis.
  • stellen Sie Ihre index.php in einen Ordner. /public/index.php .. ich denke, ein gutes framework sollte dem Entwickler erlauben, das beste zu wählen directory-Struktur. zum Beispiel in Laravel Sie können tun, was immer Sie wollen, mit der directory-Struktur. das Verhalten der Rahmen sollte niemals Auswirkungen auf die Verzeichnis-Struktur, es sollte einfach anpassbar sein.
  • sollte niemals Auswirkungen auf die directory-Struktur". Viele behaupten das Gegenteil ("convention over configuration" angepriesen, die durch die Ruby on Rails-Leute). Ich sage nicht, entweder der "richtige" ist, gibt es starke Fälle für die übereinkommen über die Anpassung: Sie können beginnen gerade zu lernen, "hier ist, wie zu tun ist", anstatt zuerst zu lernen, die vielen Möglichkeiten, die Ein erreicht werden kann und wählen Sie eine geeignete für Sie. Ein weiterer Grund ist, dass, wenn Sie die Arbeit mit diesen Konventionen in einem org, können Sie erwarten, dass Sie gleich bleiben anderswo. Schließlich, Konfiguration erfordert mehr code (aufblähen).

InformationsquelleAutor Vivek Ghaisas | 2015-07-14
  1. 15

    Ich Stimme mit dem Kommentar von Korri oben, in, dass, könnten Sie profitieren von der Einnahme von inspiration aus bestehenden frameworks.

    Persönlich, diese Art der directory-Struktur fühlt sich richtig an, für mich.

    .
|-- 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-driven richtige Antwort auf Ihre Frage. Die richtige Antwort ist spezifisch für Ihre business, das team Sie arbeiten, und das Projekt selbst.

    Ich würde nie die /vendor Verzeichnis innerhalb Ihres /src directory - weil Sie nicht eigenen es. Du bist nicht verantwortlich für die änderungen am code in Ihrem Projekt-Abhängigkeiten, so sollte es sein, die linken in Ihren eigenen Bereich außerhalb Ihrer Projekte Wänden.

    Mit PSR-4 autoloading, es spielt wirklich keine Rolle, zu viel über Ihre Verzeichnis-Struktur, kann es sich leicht zu jeder Zeit, ohne die Auswirkungen auf Ihren code. So Experimentieren und sehen, was fühlt das richtige für Sie.

    InformationsquelleAutor Amo
Schreibe einen Kommentar