Trotz der vielen PHP-Frameworks im Symfony-Umfeld und vielen zufriedenen Symfony-1.x-Nutzern – darunter zum Beispiel Yahoo und das französische Videoportal dailymotion.fr – gab es immer Verbesserungsideen, wie die Zukunft von Symfony aussehen könnte. Diese Verbesserungsideen stehen nun mit Symfony 2 [1] (von nun an groß geschrieben) und Doctrine 2 [2] – das zum Framework passende Object-Relationship-Managmentsystem – vor der Tür. Mit den neuen Versionen soll es nun noch besser möglich sein, Websites zu bauen, die schneller und sicherer sind, dabei aber auch hohen Anforderungen an Flexibilität und Produktivität gerecht werden.

Alles. Sowohl Symfony 2 als auch Doctrine 2 sind vollständige Neuentwicklungen und brechen vorsätzlich mit der Rückwärtskompatibilität, um endlich auf bewährte „Best Practices“ und, damit einhergehend, die aktuellsten technologischen Möglichkeiten setzen zu können.

Symfony 2 ist flexibler geworden. Nahezu alle Funktionalitäten sind über so genannte Bundles eingebunden, die eine konsequente Weiterführung des bisher so erfolgreichen Pluginsystems von Symfony 1.x darstellen. Außerdem haben die Entwickler strengstens darauf geachtet, alles möglichst unabhängig voneinander zu entwickeln. So existieren viele Funktionalitäten in Form der Symfony Components, die man ähnlich dem Zend Framework oder Zeta Components losgelöst vom Framework als Bibliothek einsetzen kann. Frischer Wind weht auch durch die beliebte Web Debug Toolbar, die nun mit einem integrierten Profiler daher kommt. Neu ist auch die standardmäßig integrierte Templating Engine „Twig“ [3].

Die wohl größte Neuerung bei Symfony 2 stellt der Caching-Mechanismus dar. Dieser setzt nun vollständig auf dem HTTP-Protokoll auf und wird über die dort spezifizierten Header-Anweisungen direkt vom Framework gesteuert. Der Cache selbst ist dabei kein Teil des Frameworks, sondern ein vorgelagerter Layer, den man auf Grund seiner HTTP-Kompatibilität ohne weiteres durch einen professionellen Reverse-Proxy-Server wie Squid oder Varnish austauschen kann.

Auch Doctrine 2 bietet Neues: Im Gegensatz zu früheren Versionen implementiert Doctrine 2 nun nicht mehr das Active-Record-Pattern, sondern ist der Java-Persistence-API nachempfunden, die bereits in Hibernate in der Java-Welt zum Einsatz kommt. Hier wurde ebenfalls streng darauf geachtet, die einzelnen Kern-Funktionalitäten unabhängig voneinander umzusetzen. Dass DBAL (Database Abstraction Layer) und die ORM-Komponente (Object Relation Mapper) sind von nun an voneinander getrennt. Diese Entscheidung führte zur vielleicht interessantesten Neuerung im Doctrine-Umfeld: Fast nebenher gibt es nun ein auf Doctrine 2 aufbauendes ODM (Object Document Mapper) und damit eine äußerst solide Mapping-Lösung für die NoSQL-Datenbank MongoDB [4].

Doctrine 2 ist seit Dezember 2010 in einer stabilen Version verfügbar. Die Veröffentlichung von Symfony 2 ist jedoch offiziell erst für den Hacking Day während der Symfony Live Conference 2011 [5] angekündigt, die vom 5. bis 9. März in Paris stattfindet. Fabien Potencier, Chefentwickler des Frameworkes, nennt diesen Zeitplan ambitioniert, aber machbar. Wichtiger als den Termin einzuhalten sei es allerdings, ein wirklich vollständiges Release zustande zu bringen. Die Schwierigkeiten sieht er aber eher darin zu entscheiden, welche Features es nicht mehr in das erste Release schaffen.

Technisch kann man Symfony 2 und Doctrine 2 durchaus als neue Technologien bezeichen und sie damit in Konkurrenz zu ihren Vorgängerversionen sehen. Die Philosophie hinter Symfony 2 ist jedoch dieselbe wie zuvor – Entwickler, die mit Symfony vertraut sind, werden sich schnell zurecht finden. Ähnlich ist es mit Doctrine: Die Entwickler haben genau die Dinge geändert, die vorher oft hinderlich und damit verantwortlich für viele Workarounds waren.

Dennoch muss man sich bei einem Umstieg auf die neuen Versionen bewusst sein, dass es keinen vollautomatisierten Upgrade-Prozess gibt und man bestehenden Code in den meisten Fällen aufwändig von Hand portieren muss.

Ein Blick auf die Website der neuen Framework-Version offenbart die üblichen Verkaufsargumente jedes neuen Frameworks: schneller, leicht erlernbar, einfach, erweiterbar, flexibel, vollständig und auf offene Standards aufsetzend. Wer die Neuerungen verstehen will, muss auch einen Blick in die Vergangenheit werfen.

Die Motive für den Neuanfang erklärt der Symfony-Lead-Entwickler Fabien Potencier wie folgt: Symfony 1.x entstand ursprünglich aus der Kombination des Mojavi Frameworks und des Propel ORM. Im Zuge der Entwicklung wurde Propel herausgelöst, sodass es – zunächst optional, später als Standard – durch Doctrine ersetzt werden konnte.

Der Aufbau von Symfony 1.x nach dem MVC-Pattern entstammt jedoch weiterhin Mojavi und bildet nach wie vor die Basis-Architektur. Einen so zentralen Baustein kann man nicht rückwärtskompatibel refaktorieren und verbessern, da er an vielen Stellen die Kommunikation der einzelnen Bausteine vorgibt. Dennoch war es notwendig, genau diesen Teil zu verbessern, da er an vielen Stellen unintuitiv, imperformant und in seiner konkreten Implementierung letztlich oft Quelle für Entwicklungsfehler war. Viele Best Practices wie Dependency Injection und Inversion of Control, die sich in den vergangenen Jahren ergaben, ließen sich mit dieser Architektur nicht mehr umsetzen. Außerdem war ein Bruch der Rückwärtskompatibilität unumgänglich, wenn man die neuen Möglichkeiten von PHP 5.3, etwa den Einsatz von Namespaces, nutzen wollte.

Symfony 2 ist nach wie vor ein Full-Stack-Framework und eine gute Wahl für zukünftige Projekte oder auch für solche, die noch lange weiterentwickelt werden. Man muss sich jedoch bewusst sein, dass sich bis zum für Anfang März geplanten Final-Release noch einige große Änderungen ergeben werden. Die unkomplizierte Webentwicklung mit Symfony 2 trübt das natürlich, da man gezwungen ist, ständig über alle wichtigen Änderungen informiert zu bleiben und diese in seinen Symfony-2-Projekten nachzuziehen.

Da Doctrine 2 inzwischen schon als offizielle Stable-Version veröffentlicht wurde, stellt sich die Situation hier besser dar. Nicht zuletzt der schiere Performance-Vorteil gegenüber Doctrine 1.x macht Doctrine 2 zur ersten Wahl, selbst dann, wenn man erstmal noch weiter auf Symfony 1.x setzen möchte. Zudem existieren Migrationsskripte, die den Wechsel von Doctrine 1.x auf Doctrine 2.x vereinfachen.

In der Vergangenheit haben einige Unternehmen bereits schmerzhafte Erfahrungen mit der Umstellung von Symfony 1.0 auf 1.1 gemacht und auch die nachfolgenden Versionen waren je nach Komplexität des Projekts nicht ganz unaufwändig zu aktualisieren. Nun kommt mit der Version 2 ein gänzlich inkompatibles Release und weckt daher die Skepsis bezüglich zukünftiger Versionen.

Die Struktur des neuen Frameworks mit seinen unabhängigen Komponenten wirft außerdem die Frage auf, wie sich zukünftige Releases realisieren lassen, wenn doch zu erwarten ist, dass die einzelnen Bestandteile ihr eigenes Leben mit eigenen Release-Zyklen entwickeln. Bisher gibt es dazu noch keine offizielle Stellungnahme. Aber zukünftige Entwicklungen könnte man so eventuell kontinuierlicher integrieren und somit größere Upgrades vermeiden. Sicher ist, dass Symfony 2 erneut ein „Long Term Support Release“ ist und so die Weiterentwicklung und Bugfixes für einige Jahre garantiert.

Mit Symfony 2 und Doctrine 2 werden der PHP-Gemeinde zwei professionelle Projekte zur Verfügung gestellt, die eine kluge Weiterentwicklung ihrer Vorgänger-Versionen darstellen und die man sich als 1.x-Nutzer heute schon anschauen sollte. Zwar fällt der Wechsel zu den neuen 2er-Versionen aufgrund der grundlegenden Verbesserungen nicht immer leicht, dieser Intialaufwand amortisiert sich jedoch durch die überwältigende Anzahl an neuen Möglichkeiten und der Arbeitserleichterung im täglichen Einsatz.