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
- Der Client fordert index.php .
an
- Die Konfiguration, Anbieter, Basiscontroller, Basismodell sind enthalten.
- Der DI-Container und die Abhängigkeiten werden initialisiert, wir können sie jetzt überall einfügen.
- Wir ordnen die Controller der URL zu und der Router erledigt seine Aufgabe.
- 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.
- Das Modell wird abgerufen.
- Mehr Zeug.
- Das Modell ruft dann
::call_view()
'auf, das die entsprechende Ansicht von core / views / enthält.
- 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 ...
- Ist nur der grundlegende Ordner Struktur -
core{, /controllers, /models/, /views}
, vendors
im Stamm - sieht für Sie gut aus?
- Ich glaube, ich sollte
__autoload()
außerhalb von index.php bekommen, was mir etwas zu groß erscheint. Wenn ja, was ist mit DI-Container?
- Wenn ich mehr als zwei externe Bibliotheken benötige, sollte es besser sein, sie nicht manuell einzeln zu integrieren? Aber wie?
- 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?
- 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?
- 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.