Arbeitsweise des Zend Framework 2

Nachdem wir nun eine funktionsfähige Applikation haben und einen ersten Eindruck von der inneren Struktur bekommen haben, wollen wir uns die Sache etwas genauer ansehen. Was passiert eigentlich, wenn eine Zend-Applikation eine Anfrage abarbeitet?

der Webserver

Betrachten wir den Fall, dass die Zend-Applikation von einem Apache Webserver verwaltet wird. Dann passiert folgendes:

• Eine Anfrage erreicht den Webserver. Die URL der Anfrage besteht aus Domain und Pfad. (z.B.http://localhost/application -> Domain: localhost; Pfad -> application)
• Ist der Apache wie oben beschrieben mit der Rewrite-Engine konfiguriert, versucht er die Anfrage auf folgendem Weg einer Datei zu übergeben.
  • zuerst wird versucht den Pfad einer Datei oder einem Verzeichnis zuzuordnen und die Anfrage an diese Datei weiterzureichen.
  • Kann der Pfad keiner Datei und keinem Verzeichnis zugeordnet werden, wird die Anfrage der Datei index.php übergeben.
  • Achtung: D.h. nur wenn der Pfad keinem Verzeichnis bzw. keiner Datei zugeordnet werden kann, wird die Zend-Applikation überhaupt angesprochen!
• Tritt die Zend-Applikation in Aktion ist das Ergebnis im Normalfall eine Webseite, die dem Apache übergeben wird, der sie dann an den Absender der Anfrage weiterreicht.

index.php

• In der index.php wird das Zend-Framework zuerst lauffähig gemacht, indem in das korrekte Verzeichnis gewechselt wird.
• Dann wird der Autoloading-Mechanismus gestartet wird, damit ab jetzt jede benötigte Datei des Frameworks bei Bedarf nachgeladen werden kann.
• Als nächstes wird das Framework initialisiert, um eine Umgebung zu schaffen, in der die eingegangene Abfrage abgearbeitet werden kann
• Als letztes wird das Framwork gestartet, die Abfrage damit abgearbeitet und das Ergebnis davon zurückgegeben.

Initialisierung des Frameworks

• ServiceManager: Zuerst wird der ServiceManager gestartet. Er ist eines der wichtigsten Teile einer Zend-Applikation, weil durch ihn alle weiteren Teile zur Verfügung gestellt werden. Der ServiceManager weis z.B. wie komplexe Objekte über Factories gebaut werden oder wie die Konfiguration des Systems aussieht.
  • Ist der ServiceManager gestartet wird die übergebene Konfiguration als Service eingebunden, so dass im späteren Verlauf der Applikation darauf zugegriffen werden kann.
• ModuleManager: Im nächsten Schritt der Initialisierung erzeugt der ServiceManager den ModuleManager und gibt ihm die Aufgabe, die Module zu laden und in die Applikation einzubinden.
• Application: Als letztes erzeugt der ServiceManager die eigentliche Applikation und fordert sie auf, den restlichen Initialisierungsvorgang zu übernehmen. Die Applikation unternimmt dabei folgende Schritte
  • sie besorgt sich das Request-Objekt, das alle Parameter der Anfrage enthält
  • sie besorgt sich das Response-Objekt, das am Ende die Antwort der Applikation enthalten wird
  • sie startet den EventManager und übergibt ihm verschiedene Listener für die Events
  • sie triggert den Bootstrap-Event, um anderen Teilen der Applikation (z.B. die Module) d ie Möglichkeit zu geben ihren Initialisierungsprozess zu starten

Abarbeiten der Anfrage

Ist die Applikation initialisiert kann nun die Abfrage abgearbeitet werden. Dies geschieht in folgenden Schritten:

• Routing: Beim Routing wird die Anfrage einem Controller zugeordnet. Für die Entscheidung wird vor allem der Pfad der URL benutzt. Prinzipiell können aber auch andere Parameter verwendet werden.
• Dispatch: Ist klar welcher Controller angesprochen werden muss, wird er gestartet und bekommt die Parameter der Anfrage übergeben.
• Rendering: Ein Controller gibt im Normalfall ein ViewModel also eine Datenstruktur zurück, die zuerst mit Hilfe von Templates in eine Webseite verwandelt werden muss. Ein Controller hat auch die Möglichkeit eine Response zurückzugeben. Dann wird das Rendering übersprungen.
• Finish: Nach dem Rendering kommt das Beenden der Applikation. Hier kann z.B. die Abmeldung von externen Zugriffen auf Webservices oder Datenbanken erledigt werden