Front Controller Pattern – Definition

Posts in this series
  1. Front Controller Pattern - Definition
  2. Routing im Front Controller

Das Front Controller Pattern dient dazu, dass jede Anfrage in einer Anwendung an demselben Einstiegspunkt landet. Das bedeutet, dass man vom Browser aus (neben statischen Ressourcen wie CSS, JavaScript oder Bildern) nur ein einziges PHP-Script aufrufen kann. Dies hat einige Vorteile.

Problem

Früher wurden PHP-Anwendungen so geschrieben, dass jede “Seite” auf einer Website ein eigenes Script hatte (z.B. login.php, category.php usw.). Dieses Script war speziell für einen Aufruf auf diesen Teilbereich der Webseite “optimiert” und verarbeitete die Eingabevariablen so, dass am Ende ein fertiges Dokument entstand.

Mit einer solchen Anwendungsstruktur gibt es allerdings ein entscheidendes Problem: Bei jedem Request müssen oft die gleichen Dinge getan werden. Ich will es am Beispiel der Filterung der Eingabevariablen erklären. Wenn diese Filterung in jedem Script separat durchgeführt wird, führt dies zwangsläufig zu dupliziertem Code. Dieser gehört zu den gravierendsten Ursachen von schlecht wartbarem Code und sollte unbedingt vermieden werden!

Man stelle sich z.B. vor, dass eine neue Angriffsmethode bekannt geworden ist und nun die Filterung der Eingabevariablen entsprechend angepasst werden muss. Das würde bedeuten, dass diese Anpassung in jedem von außen aufrufbaren Script vorgenommen werden müsste – einer enormer Aufwand.
Außerdem kann es passieren, dass ein anderer Programmierer von dieser nötigen Anpassung nichts weiß und die Filterung der Eingaben weiterhin wie bisher vornimmt. Vergisst man dementsprechend in nur einem einzigen Script, das von außen aufrufbar ist, diese Anpassung, bestünde ein Sicherheitsleck.

Ein weiteres Problem ist die fehlende Abstraktion gegenüber dem Protokoll. Es wird einfach vorausgesetzt, dass es sich um einen HTTP-Request handelt und dass folglich bestimmte superglobale Variablen wie $_GET oder $_POST usw. gefüllt sind. Wenn wir uns nun darauf verlassen, dass diese Variablen existieren, verstoßen wir gegen einen wichtigen Grundsatz der objektorientierten Programmierung: Programmiere niemals gegen eine konkrete Implementierung – schon gar nicht gegen eine Implementierung, die man nicht selbst beeinflussen kann – sondern immer gegen eine Schnittstelle! Der Request sollte deshalb in einem Interface abstrahiert werden. Auf diese Art und Weise könnte der Front Controller später ebenfalls für andere Protokolle genutzt werden, z.B. wenn die Anwendung zukünftig als Desktopanwendung oder App erscheinen soll, die nicht auf HTTP basieren.

Ähnliches gilt für das Senden der Ausgabe. Wenn es mehrere Stellen in der Anwendung gibt, an denen eine Ausgabe vorgenommen wird (z.B. mit echo), dann nimmt man sich die Möglichkeit wird es schwieriger, bestimmte Ausgabefilter anzuwenden oder die ganze Ausgabe anders zu verarbeiten als nur als Bildschirmausgabe.

Zielsetzung des Front Controller Patterns

Der Front Controller löst dieses Problem nun, indem alle nicht-statischen Anfragen bei einem einzigen Script auftreffen – nennen wir es index.php. Daneben gibt es wie bisher viele weitere Scripte und Klassen, die allerdings nicht von außen aufrufbar sind. Der einzige Einstiegspunkt zur Anwendung ist die index.php und die darin aufgerufene Front-Controller-Klasse. Dort werden alle Operationen ausgeführt, die bei jedem Request nötig sind.

Wenn es nur noch einen zentralen Einstiegspunkt in die Anwendung gibt, muss irgendwie festgelegt werden, an welchen Controller die weitere Verarbeitung der Anfrage delegiert wird. Bisher wurde diese Aufgabe durch die unterschiedlichen Scripte übernommen. Im Request muss nun also irgendwo festgelegt werden, welcher Controller vom Front Controller aufgerufen werden soll. Dies kann beispielsweise in Form eines GET-Parameters geschehen, z.B.

index.php?view=login
. Welcher Controller anschließend bei einem bestimmten Request-Parameter genau aufgerufen wird, bestimmt die Routing-Klasse.

Wir halten folgende Aufgaben des Front Controllers fest:

  • Definition eines eindeutigen Einstiegspunktes in die Anwendung – kein anderes Script ist von außen erreichbar
  • Abstraktion des Requests und der Response -> Entkopplung der Anwendung aus dem Webumfeld
  • Operationen, die bei allen Requests ausgeführt werden sollen, werden zentral und somit nur einmalig implementiert
  • Routing von Requests zur auszuführenden Controller-Klasse, die das Antwort-Dokument generiert
  • neue Unterseiten müssen einfach hinzuzufügen sein, ohne dass vorhandene Scripte angepasst werden müssen

Ein Vorschlag für eine Umsetzung dieses Patterns zeige ich in den nächsten Beiträgen.

Posts in this series
  1. Front Controller Pattern - Definition
  2. Routing im Front Controller

Jan hat 152 Beiträge geschrieben

Eine Antwort schreiben

Ihre E-Mail-Adresse wird nicht veröffentlicht. Benötigte Felder sind markiert mit *

You may use these HTML tags and attributes: <a href=""> <blockquote cite=""> <pre lang=""> <b> <strong> <i> <em>