Nein, aber….

Von Frickelcode zu so etwas wie MVC

Ich bin seit 2001 hauptberuflich PHP-Developer. Ich habe Frameworks und CMS kommen und gehen sehen. Meine ersten Projekte begangen mit einem komplett leeren Verzeichnis und einer komplett leeren Datei namens index.php. Alles, was passierte, musste ich erst einmal erfinden. Ganz am Anfang, zu PHP3-Zeiten war nicht einmal objektorientierte Programmierung ein Thema.

Aber schon damals habe ich gemerkt, dass ich bestimmte Dinge immer wieder tun muss. Allein schon die Verbindung zu einer MySQL-Datenbank wurde meistens direkt in eine Datei namens db.php ausgelagert und diese Datei hat nicht nur die Verbindung geöffnet, sondern auch gleich ein Handle zur Verfügung gestellt, mit dem ich projektübergreifend meine SQL-Befehle schreiben konnte. Später kam noch hinzu, dass ich die Input-Variablen noch validieren musste. So wurde ganz am Anfang eine Funktion geschrieben, die sowohl den Request-Parameter als auch den erwarteten Datentyp prüfte und im Fall eines Fehlers direkt ein boolsches FALSE ausgab. Ganz nebenbei wurden natürlich Anführungszeichen escaped.

Ohne es zu wissen, habe ich damit schon eine Art Layer für Datenbanken programmiert, weil ich später dazu übergegangen bin, meine Tabellen als Klassen mit Gettern und Settern zu schreiben. In den Funktionen habe ich genau definiert, wie die Tabellenspalte formatiert ist, welche Eingabewerte als „in Ordnung“ galten und was letztendlich bei Falscheingaben funktionieren sollte. Das war quasi mein erster Datenbank-Layer.

Spätestens dann habe ich mich damit befasst, was genau ich eigentlich will? Was soll passieren, wenn eine URL auf eine bestimmte Art aufgerufen wird und was passiert, wenn der Aufruf Müll ist. Ich fummelte herum und fand irgendwann heraus, dass im Grunde die index.php als so eine Art Router funktioniert, der erlaubten Input weitergibt und bei allen Dingen, die irgendwie „komisch“ sind, einen 404- oder sogar 500-Fehler produziert. In der Datei wurde festgelegt, welches Template bei Aufruf XYZ geladen wird und welcher Programmcode inkludiert wird. Die Session und mein DB-Layer standen in der index.php global zur Verfügung und ohne genau zu wissen, was ich da programmiert habe, stellte ich fest, dass das schon eine Art „Design-Pattern“ war. Es gab also hier schon einen einfachen Model-View-Controller. Das Modell war meine kleine Tabellenklasse, der Controller war ein einfaches Skript, das den zu ladenen View bestimmte und ein bißchen Businesscode ausführte.

Mit diesem einfachen MVC habe ich über Jahre mässig gute Websites gekriptet. Ich wusste genau, was rein kommt und was rausgeht. Ich habe es komplett verstanden und war glücklich, zumindest bis ich mir das Ding 5 Jahre später noch einmal angucken musste. Tatsache ist, dass man seinen eigenen Code danach nicht mehr so gut auswendig kann. Wenn man das doch kann, sollte man lieber alles mögliche auswendig lernen und versuchen, bei „Wer wird Millionär“ mehr zu gewinnen, als mein Lieblingscomedian Bastian Bielendorfer. Sich alles zu merken, was man irgendwann einmal programmiert hat, ist unmöglich.

Frameworks

PHP-Frameworks, wie Laravel, Symfony, CodeIgniter und Zend haben alle oben genannten Features. Es ist immer ein Sessionhandling dabei, die grundsätzlichen Vorlagen für Userauthentifizierung sind dabei, die Verbindung mit beliebigen Datenbanksystemen sind möglich, ohne dass man heute noch SQL können muss und nicht zuletzt gibt’s im Frontend schon alles, was man für schnellen Seitenaufbau (Caching) und den Ansatz „mobile-first“ benötigt. Eine Website, die mit einem Full-Stack-Framework gebaut ist, komprimiert deine CSS-Dateien automatisch, scannt permanent Fehler in deinem Javascript (weil Webkit fehlerhaftes JS nicht komprimiert) und die Dinger sind so gut vorbereitet, dass du im Regelfall nicht später noch kompliziert alle möglichen SQL-Abfragen umschreiben musst, weil deine selbstprogrammierte Blogsoftware nun doch zwischen Administrator, Redakteur und Gastautor unterscheiden muss.

Du kannst sogar wählen, ob’s eine Website ist oder deine Programmierung nur JSON/XML-Daten raushaut, die dann von einer App geladen werden und parallel noch ein Skript hosten, dass die API-Daten als Website zusätzlich darstellt. Dabei bist do sogar so flexibel, dass du dank integrierter Unterstützung für vorhandene APIs ohne Zusatzaufwand Drittsysteme ansteuern kannst. Alles ist schon fertig programmiert.

Klar ist der Quellcode von diesen eierlegenden Wollmichsäuen viel größer als deine index.php, die security.php und die db.php aber es zwingt dich auch niemand, die Gesamtheit des Quellcodes zu nutzen. Ich glaube, selbst die größten Enterprise-Websites der Welt nutzen nicht alles, was ein Framework zur Verfügung stellt. Denn unter der Haube ist es noch immer „Vanilla-PHP“, was bedeutet, dass du eben problemlos weiterhin am Framework vorbei programmieren kannst, was du aber tatsächlich vermeiden solltest.

Insofern bleibt die Überschrift ja gültig: PHP-Frameworks sind ein großer Hype. Das ist aber eben nichts schlechtes. Denn die Anwendung eines Frameworks unter Berücksichtigung von Programmierstandards, die von hunderten und tausenden von Programmierern verabschiedet wurden, sorgt so für viel besseren Code.

Als erfahrener Senior-Entwickler kann ich mit Sicherheit sagen, dass die Verwendung von PHP-Frameworks wie Symfony oder Laravel einen erheblichen Mehrwert für die PHP-Entwicklung bietet. Erstens bieten Frameworks eine strukturierte und organisierte Herangehensweise an die Entwicklung, was die Wartbarkeit und Skalierbarkeit des Codes verbessert. Durch die Verwendung von vorgefertigten Modulen und Komponenten ermöglichen Frameworks auch eine schnellere Entwicklung von Anwendungen und eine Reduzierung des Bedarfs an wiederholtem Code.

Darüber hinaus bieten sie eine aktive Community, die kontinuierliche Aktualisierungen und Sicherheitspatches gewährleisten. Frameworks erleichtern auch das Testen von Code und stellen bewährte Methoden und Entwurfsmuster zur Verfügung, die die Qualität und Zuverlässigkeit von Anwendungen verbessern. Schließlich erleichtern sie die Entwicklung komplexer Anwendungen, indem sie die Integration von Bibliotheken und APIs von Drittanbietern ermöglichen.

Tolle Slideshow von Ralf Eggert. Wir hatten ja nix.