Kolumne: Zeit für PHP

Symfony, Zend Framework & Co: Die Geschichte der PHP-Frameworks
Keine Kommentare

Erst mit dem Jahr 2005 beginnt die Geschichte der PHP-Frameworks. Das ist erstaunlich, da die Programmiersprache PHP selbst bereits im Jahr 1995 von Rasmus Lerdorf entwickelt wurde. Wie sind Frameworks wie Symfony, Zend Framework und Co so groß geworden? Und wer hat das beste Framework im ganzen Land? Antworten auf diese Fragen möchten Arne Blankerts und Stefan Priebsch (thePHP.cc) in dieser Ausgabe der PHP-Kolumne „Zeit für PHP“ geben.

Die Geschichte der PHP-Frameworks beginnt in der Mitte der Nullerjahre, genau genommen 2005. Denn obwohl PHP eigentlich bereits seit 1995 existiert, war erst mit Version 4 eine rudimentäre Unterstützung von etwas verfügbar, das man aus heutiger Sicht mit viel gutem Willen als Objektorientierung bezeichnen mag. Das hinderte freilich einige Wagemutige nicht daran, erste objektorientierte Gehversuche zu unternehmen und Bibliotheken und Klassen zu veröffentlichen, die zumeist einfach nur bestimmte Funktionalitäten bündelten: PEAR, das PHP Extension and Application Repository, war geboren. Und wenn gleich diese Lösungen wenig mit dem zu tun haben, was man heute unter einem Framework verstehen mag, findet sich das modulare Konzept von PEAR auch in modernen Frameworks wieder.

Bis zur nächsten Generation von Frameworks in PHP brauchte es die Version 5 der Sprache in 2004 – jetzt mit ernstzunehmender Unterstützung für objektorientierte Entwicklung –, den Dotcom-Boom und nicht zuletzt den Dänen David Heinemeier Hansson. Ob man aus Sicht von PHP heute stolz darauf sein sollte, den Dotcom-Boom begünstigt zu haben, ist vermutlich eine Frage, über die man hervorragend diskutieren oder gar streiten kann. Unstrittig hingegen ist, dass David Heinemeier Hansson mit seinem Framework Ruby on Rails auch und gerade auf die PHP-Welt einen großen Einfluss hatte und vermutlich bis heute hat.

Wie die Frameworks groß wurden

Die PHP-Community schaute anfangs durchaus neidisch auf die ersten Erfolgsmeldungen, wie produktiv man doch mit einem Framework wie Ruby on Rails programmieren könne. Zugegebenermaßen ist ein Vergleich zwischen einer Programmiersprache und einem Framework nicht gerade sinnvoll, aber wer fragt in der heutigen (Medien-)Welt noch nach der Sinnhaftigkeit von Vergleichen? Das Standardbeispiel für Ruby-on-Rails-Anwendungen, die Erstellung eines Blogs in weniger als zehn Minuten, war durchaus beeindruckend, täuscht aber über die Komplexitäten einer realen Anwendung mit ernsthafter Geschäftslogik hinweg. Hinzu kommen die aus heutiger Sicht problematische Verwendung von Active Record und die starke Kopplung von Code an die dahinterstehende Datenbank. Wohl auch aus der Befürchtung heraus, dass PHP – nicht zuletzt wegen des Rails-Frameworks – Marktanteile an Ruby verlieren könnte, und weil es zu diesem Zeitpunkt kaum ernstzunehmende PHP-Frameworks gab, kündigte die Firma Zend ein eigenes quelloffenes Produkt an: Das Zend Framework.

Auch interessant: Zend Framework und die Linux Foundation – die Zukunft von Laminas

Bis zu dessen erstem Release am 30. Juni 2007 sollten allerdings rund zwei Jahre vergehen. Zeit, in der auch andere Entwicklerteams an ihren Frameworks für PHP arbeiteten und von denen einige eine durchaus beachtliche Verbreitung erreichten. Den Anfang unter den bekanntesten Frameworks dürften 2005 die Frameworks CakePHP, Agavi und Symfony 1 gemacht haben, gefolgt von CodeIgniter in 2006 und dessen Fork Kohana in 2007. Selbstverständlich entstanden nicht nur allgemein verwendbare Frameworks, sondern auch mehr oder weniger schlüsselfertige Lösungen für Content-Management-Systeme, interaktive Portale oder das Erstellen von Onlineshops. Neben TYPO3 und Drupal stieg vor allem Magento zu einer der beliebtesten (und häufig gehassten) Plattformen für E-Commerce auf. Fun Fact: Ursprünglich von Zend als Showcase für die Leistungsfähigkeit des eigenen Frameworks angepriesen, verwendete Magento 1 nur sehr wenige Teile einer frühen Vorversion des Frameworks, und selbst dabei wurden die zugrunde liegenden Konzepte fast bis zur Unkenntlichkeit verbogen.

Wer hat das beste Framework im ganzen Land?

Die zunehmende Vielfalt an Frameworks und Konzepten brachte schnell die Frage mit sich, welches Framework denn nun das beste sei. Diese Frage scheint natürlich nahe zu liegen, wenn man schon nicht (mehr) fragen darf, welche Programmiersprache denn nun die beste ist. Die Diskussionen, die sich an die Versuche einer Beantwortung anschließen, sind freilich in höchstem Maße religiös. Entwickler können schließlich über kaum ein Thema so trefflich streiten, außer vielleicht über Einrückungen und die Frage, an welche Stelle man geschweifte Klammern setzen soll. Gegen Ende der Nullerjahre dachten sich daher auch verschiedene Konferenzveranstalter, dass eine öffentliche Framework-Diskussion unterhaltsam sein müsse. Wenn schon die Anwender einzelner Frameworks dazu neigen, sich über die Frage, wessen Framework das bessere sei, die Köpfe einzuschlagen, was würde dann erst geschehen, wenn man Kernentwickler verschiedener Frameworks gemeinsam in eine Panel-Diskussion setzt? Wir erinnern uns an eine Konferenz, in der ein – natürlich amerikanischer – Veranstalter vorsorglich auf jeden Platz eine geladene Nerf-Gun gelegt hatte.

Kostenlos: IPC Agile Cosmos Cheat Sheet

Agile Cosmos Cheat Sheet-small-220x311In diesem Cheat-Sheet von unserem Experten René Schröder bekommen Sie einen Überblick über den Agile Cosmos und die organisatorische Struktur. Mit diesem Mind-Map haben Sie die perfekte Voraussetzung, um entweder Ihr eigenes agiles Team aufzubauen, Ihre aktuelle Organisation zu verbessern oder einen eigenen Stil von Agil zu kreieren.


Was dann geschah, muss eine bittere Enttäuschung für die Veranstalter gewesen sein: Die Vertreter der verschiedenen Frameworks, die sich ohnehin untereinander kannten, sprachen sich gegenseitig großen Respekt aus, lobten hier und da den technischen Vorsprung der „Konkurrenz“ und erzählten, an welchen Stellen man sich vom jeweils anderen hatte inspirieren lassen. Den im Titel der Veranstaltung beschworenen „War of the Frameworks“ hatte es so nie gegeben. Die PHP-Community, auch wenn es nach außen nicht immer den Anschein hat, war immer schon stark miteinander verwoben. Wer nicht nach Marktanteilen streben muss, um den eigenen Umsatz weiter zu erhöhen und immer wieder neue geschäftliche Erfolgsmeldungen zu veröffentlichen, der kann sich, ähnlich wie PHP als Sprache es auch tat und weiterhin tut, von Ideen, Konzepten und Lösungen anderer inspirieren lassen. Dabei ist es vor allem dieses „voneinander lernen“, das die Innovation beschleunigt. In einer quelloffenen Welt geht das noch besser und noch schneller, da man den Quelltext der anderen ohne technische und juristische Hürden einfach einsehen und – je nach Lizenz – sogar direkt übernehmen oder als Komponente in die eigene Lösung integrieren kann.

Fabien Potencier, Gründer von SensioLabs und Vater von Symfony, hat sich in diesem Zusammenhang in der PHP-Community verdient gemacht wie kein Zweiter. Er hat es immer schon verstanden, über den Tellerrand von PHP hinaus zu schauen und von anderen Sprachen und deren Frameworks zu lernen. Auf diese Weise hat er neue Ideen und viele Best Practices in die PHP-Community gebracht. Symfony war insofern all die Jahre ein Innovationstreiber in der PHP-Welt und hat viele andere Lösungen und Frameworks beeinflusst. Dabei muss man selbstverständlich nicht mit allen Entscheidungen, Konzepten und daraus resultierenden Lösungen einverstanden sein, doch so manche Innovation ist – zumindest in der Welt der PHP Frameworks – heute kaum mehr wegzudenken.

Das konsequente Setzen auf DI (Dependency Injection) beispielsweise, das in der objektorientierten Programmierung eigentlich eine Selbstverständlichkeit sein sollte, war in der PHP-Entwicklung nicht immer das so selbstverständliche Mittel der Wahl wie heute. Im Unconference-Track am Rand einer ZendCon in Santa Clara, wo es eine Session zum Thema Dependency Injection gab, saßen Fabien, Stefan und einer der Kernentwickler des Zend Frameworks, Ralph Schindler, zusammen und diskutierten das Für und Wider von DI. Ralph war dabei eingangs wenig überzeugt, warum man Dependency Injection überhaupt einsetzen sollte. Offensichtlich waren aber die Argumente von Fabien und Stefan überzeugend, denn beim nächsten Release erhielt Zend Framework unter anderem eine neue Komponente, nämlich einen Dependency-Injection-Container, geschrieben von eben jenem Ralph Schindler.

Warum das Framework nur eine Kontrollflussumkehr ist

Interessant ist, dass das Zend Framework trotz des Namens am Anfang eigentlich eher als eine lose Sammlung von Komponenten vermarktet wurde, die man gut zusammen einsetzen konnte und die einem relativ einheitlichen Entwicklungsschema folgten. Ganz anders als viele der anderen Frameworks, die einem Alles-oder-Nichts-Prinzip folgend eine feste, eher monolithische Struktur aufwiesen und daher auch als Full-Stack Framework bezeichnet werden. Was uns zu einer spannenden Frage führt: Was eigentlich ist ein Framework? Fragt man das Internet, erhält man, wie so häufig, unzählige Erklärungen, die sich zum Teil auch noch widersprechen. Dabei ist etwas akademisch formuliert ein Framework einfach nur eine Kontrollflussumkehr (Inversion of Control). Das bedeutet in der Praxis, dass eine Anwendung nicht selbst den Kontrollfluss steuert, sondern das eben dem Framework überlässt. So können wiederkehrende Abläufe einmal generisch abgebildet werden, sodass der Anwendungsentwickler sich auf das Schreiben der Anwendung selbst konzentrieren kann, deren Bestandteile dann jeweils vom Framework aufgerufen werden.

Die meisten Frameworks in der PHP-Welt kümmern sich wenig überraschend um die Abstraktion von HTTP-Anfragen und wollen es dem Entwickler so leicht wie möglich machen, eine Anwendung zu erstellen und mit dem Internet zu integrieren. Viele Frameworks behaupten dabei von sich, auf das MVC-Entwurfsmuster zu setzen. Dass das bereits 1979 von Trygve Reenskaug für Desktopanwendungen in Smalltalk erdachte Model-View-Controller-Pattern im Web und über Client-Server-Grenzen hinweg konzeptionell gar nicht funktionieren kann, wurde und wird einfach ignoriert. Die Folge ist, dass niemand so genau beantworten kann, welcher Code eigentlich ins Model und welcher in den Controller gehört, auch die Autoren der jeweiligen Frameworks nicht. Nur bei der View sind sich die meisten dann wieder mehr oder weniger einig. Doch egal für welches HTTP-Framework man sich entscheidet, der Kontrollfluss für das Beantworten einer HTTP-Anfrage ist immer gleich: Abhängig davon, was für ein Request vorliegt, muss entschieden werden, welcher Code auszuführen ist – ein Vorgang, den man Routing nennt. Um das Ergebnis darzustellen, kommt dann meist HTML und somit die eben erwähnte View zum Einsatz. Fehler werden in entsprechende HTTP-Fehlercodes umgewandelt oder, im Falle von Formularverarbeitung, nutzerfreundlich aufbereitet.

Formular- beziehungsweise Datenverarbeitung ist übrigens ebenfalls ein typischer Anwendungsfall für ein Framework zur Kontrollflussumkehr. Statt den Kontrollfluss zu implementieren, definiert der Anwendungsentwickler nur das Formular selbst, legt fest, mit welchen Werten es vorpopuliert werden soll, und definiert dann die Validierungsregeln mit den entsprechenden Fehlermeldungen. Im Anschluss muss nur noch festgelegt werden, welche Aktion(en) im Erfolgs- und welche im Fehlerfall ausgeführt werden sollen. Die Steuerung übernimmt dann der Inversion-of-Control-Container, im einfachsten Fall eine selbstgeschriebene abstrakte Basisklasse. Auch ein vermeintlich modernes CQRS Framework sieht im Grunde nicht viel anders aus, nur dass eben zwischen Kommando (Command) und Anfrage (Query) unterschieden wird und diese getrennt geroutet werden. Hinzu kommt, dass Kommandos normalerweise keine Inhalte zurückgeben, während Anfragen offensichtlich dazu dienen, Content auszuliefern. Dass diese Inhalte im Idealfall bereits außerhalb des Requests statisch erzeugt wurden und so in einer optimal zur Anfrage passenden Form vorliegen, ändert am eigentlichen Verarbeitungsablauf nur wenig.

Interessant wird es, wenn sich Anforderungen ändern und das dazu führt, dass grundlegende Annahmen vor allem des Frameworks nicht mehr zutreffen: Was passiert, wenn statt HTML mit JSON geantwortet werden soll oder der gleiche Geschäftsvorfall unabhängig und ohne einen auslösenden HTTP-Request verarbeitet werden muss? Wie sieht es aus, wenn anstelle einer vollständigen HTML-Seite dynamische, kleine Fragmente in verschiedenen Formaten benötigt werden? Klassische Full-Stack-Lösungen wie Magento oder Typo3 leiden noch heute darunter, dass ihre Architektur auf derart geänderte Anforderungen nicht wirklich ausgelegt ist. Wer die Geschäftslogik seiner eigenen Anwendung nicht sauber isoliert entwickelt hat, sondern eng mit dem Framework verzahnt, bekommt hier ebenfalls ein Problem. Die Lösung dafür ist dann oft ein Werkzeug wie Wget, mit dem von der Kommandozeile aus ein HTTP-Request ausgelöst wird. Oder es kommen mitunter komplexe zusätzliche Technologien zum Einsatz, um die gelieferte Seite zu zerschneiden, zu parsen oder zu konvertieren.

Ein Framework muss einfach nur eine Aufgabe effizient lösen

Spannenderweise führt die Erkenntnis, dass mit dem bisher verwendeten Framework nicht mehr alle Anforderungen abgedeckt werden können, nur selten dazu, dass man zunächst die eigentliche Geschäftslogik extrahiert. Der Regelfall scheint zu sein, dass man versucht, die aktuelle Lösung immer weiter zu verbiegen, und damit jegliche Chance auf ein Upgrade verliert oder sich die gleichen Fehler bei der Migration in ein anderes Framework direkt wiederholen. Die meisten Framework-Anbieter jedenfalls haben ihre Lektion gelernt: War ein Migrationspfad beispielsweise von Zend Framework 1 zur Version 2 faktisch nicht vorhanden, so sind aktuelle Frameworks durchaus darauf bedacht, die Rückwärtskompatibilität zu früheren Versionen weitestgehend zu wahren.

Für uns ist es im Beratungsalltag immer wieder interessant zu erleben, dass sich Entwickler sprichwörtlich bei uns dafür entschuldigen, dass man kein Framework im Einsatz habe. Neben der Tatsache, dass dies in den meisten Fällen nach der obigen Definition von Framework gar nicht stimmt, schimmert hier auch eine vollkommen unnötige Abwertung der eigenen Arbeit durch. Man muss sich weder schämen, wenn man sein eigenes Framework entwickelt hat, das auf die eigenen Anforderungen zugeschnitten ist, noch muss man sich dafür schämen, ein Standard-Framework einzusetzen.

Ein Framework muss – und sollte vielleicht sogar – dabei gar nicht als Full-Stack-Lösung implementiert sein, sondern eben genau eine Aufgabe effizient lösen. In den Zehnerjahren entstand ein klarer Trend weg vom Full-Stack Framework hin zu den so genannten Microframeworks wie Slim. Ausgelöst durch die Erkenntnis, dass ein schwergewichtiges Framework, das darauf ausgelegt ist, eine Menge Daten zu laden, um daraus dynamisch eine komplexe HTML-Seite zusammenzubauen, nicht unbedingt geeignet ist, AJAX Requests aus dem Frontend besonders performant zu beantworten. Mit den möglicherweise übertriebenen Trends hin zu Microservices und Containern scheint eine endgültige Abkehr von großer, monolithischer Software erfolgt zu sein – wenn da nicht die großen Legacy-Brocken wären, die bei den meisten Firmen noch irgendwo im Rechenzentrum im Keller lagern.

Die zwei wichtigsten Lektionen im Zusammenhang mit Frameworks sind: frage nicht, wie du von Framework X zu Framework Y migrierst, sondern frage, wie du deine Anwendung von Framework X unabhängig machen kannst – der Rest kommt dann von selbst und ist möglicherweise mit der interessanten Erkenntnis gekrönt, dass man so viel Framework gar nicht braucht. Und: ein Framework ist eine Lösungsschablone. Es liefert meist einige sinnvolle Best Practices in Form von Konventionen, Regeln oder Dokumentation mit. Man muss sich nur immer wieder bewusst machen, dass niemand, auch nicht das tollste Framework der Welt, den Anspruch darauf hat, der „one and only Way“ zu sein, etwas zu tun.

PHP Magazin

Entwickler MagazinDieser Artikel ist im PHP Magazin erschienen. Das PHP Magazin deckt ein breites Spektrum an Themen ab, die für die erfolgreiche Webentwicklung unerlässlich sind.

Natürlich können Sie das PHP Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -