Organisieren eines PHP-Projekts

8

Was es ist

Hier ist was ich bisher gemacht habe:

  • Kern /
    • controllers / (enthält die von der App verwendeten Controller)
    • models / (enthält die von der App verwendeten Modelle)
    • Ansichten / (enthält die von der App verwendeten Ansichten)
    • base_controller.php (der Controller alle anderen erweitern)
    • base_model.php (das Modell alle anderen erweitern)
  • Anbieter /
    • phprouter / (eine einfache Router-Klasse)
    • pimple / (eine einfache DI-Containerklasse)
  • configuration.php (enthält die gesamte App-Konfiguration)
  • index.php (beinhaltet die Konfiguration, Anbieter, Basismodell, Basiscontroller, setzt den DI-Container hoch und routet die Anfrage)

Siehe den Code hier: Ссылка
Bitte beachten Sie, dass der angegebene Code nur ein Beispiel ist, also die Controller, Modelle, Ansichten sind noch nicht vorhanden. Es kann auch fehlerhaft sein - als nicht getestet - aber es spielt keine Rolle.

Anforderungsfluss

  1. Der Client fordert index.php .
  2. an
  3. Die Konfiguration, Anbieter, Basiscontroller, Basismodell sind enthalten.
  4. Der DI-Container und die Abhängigkeiten werden initialisiert, wir können sie jetzt überall einfügen.
  5. Wir ordnen die Controller der URL zu und der Router erledigt seine Aufgabe.
  6. Der Controller wird abgerufen (obwohl dies nicht im Beispielcode ist, wie oben erwähnt).
    • Wir machen ein paar Sachen.
    • Die Methode ruft dann ::call_model() auf, die das entsprechende Modell aus core / models / enthält, und ruft dann dieselbe Methode auf, die wir aus der entsprechenden Modellklasse verwenden.
  7. Das Modell wird abgerufen.
    • Mehr Zeug.
    • Das Modell ruft dann ::call_view() 'auf, das die entsprechende Ansicht von core / views / enthält.
  8. Die Ansicht wird abgerufen und die Seite dem Client gerendert.

FYI: Entsprechendes

Beispiele für Controller, Modell, Ansicht, die übereinstimmen:

  • Controller Controller_Products::list() bei core / controllers / Controller_Products.php
  • Modell Model_Products::list() als core / models / Model_Products.php
  • Zeigen Sie unter core / views / Model_Products_list.php an

Probleme, denen Sie gegenüberstehen

Tatsächlich fühle ich mich mit dieser Struktur etwas unwohl. Weiß nicht, es scheint weit von skalierbar, modulierbar zu sein ...

  1. Ist nur der grundlegende Ordner Struktur - core{, /controllers, /models/, /views} , vendors im Stamm - sieht für Sie gut aus?
  2. Ich glaube, ich sollte __autoload() außerhalb von index.php bekommen, was mir etwas zu groß erscheint. Wenn ja, was ist mit DI-Container?
  3. Wenn ich mehr als zwei externe Bibliotheken benötige, sollte es besser sein, sie nicht manuell einzeln zu integrieren? Aber wie?
  4. Die gesamte Konfiguration in einer Datei zu speichern configuration.php am Stamm sieht für mich wie altmodisches PHP4 aus. Dank der Power von Pimple konnte ich diese Konfiguration direkt in sie einbetten, aber noch wo?
  5. Ich denke, die Art und Weise, wie ich mit ::call_model() ( core / base_controller.php ) und ::call_view() ( core / base_model.php ) umgehe, ist ein bisschen peinlich. Würdest du zustimmen? Was wäre eine vereinfachte Möglichkeit, das Ganze noch einmal zu wiederholen?
  6. Wäre es für mich in Anbetracht all meiner Probleme besser, ein Framework als Symfony zu verwenden?

Wenn etwas nicht klar ist, zögern Sie nicht zu fragen Danke.

    
seriousdev 15.06.2011, 11:31
quelle

1 Antwort

2
  1. Ja.
  2. Sie können Autoload und DI-Container zusammen verwenden. Es gibt ein Beispiel , wie Autoload verwendet werden kann Namenskonvention. Ich empfehle, spl_autoload zu verwenden.
  3. Mit autoload können Sie alle (oder fast alle) Includes entfernen.
  4. In index.php, denke ich.
  5. Ja, es ist falsch. Versuchen Sie zunächst, keine statischen Methoden zu verwenden. Außerdem sollten Modelle Methoden mit beschreibenden Namen haben, nicht nur "ruf mich an und ich werde alles tun, was ich kann". Es ist ein komplexeres Problem - Sie müssen verstehen, wie Controller und Modell zusammenarbeiten sollten. Als Variante lesen Sie einige Bücher. Controller sollte Methoden von Model aufrufen, um Daten für bestimmte Situationen zu erhalten. Modell es ist nicht nur Platz für Code des Controllers. Verschiedene Controller können verschiedene Modelle verwenden. Modelle können auch andere Modelle verwenden.
  6. Antwort auf diese Frage kann nicht objektiv sein:)
OZ_ 15.06.2011, 11:45
quelle