Was ist Symfony?

Die meisten Frameworks sind ein Fertighaus: Grundriss steht, man richtet ein. Symfony ist eher ein Baumarkt mit sehr gutem Sortiment. Es besteht aus Dutzenden eigenständigen Komponenten, eine fürs Routing, eine für Formulare, eine für Sicherheit, eine für die Kommandozeile, und jede lässt sich einzeln oder im Verbund nutzen. Wer eine komplette Anwendung baut, nimmt das Gesamtpaket. Wer nur einen Baustein braucht, nimmt nur den.

Diese Bauweise hat Symfony zu einer besonderen Rolle in der PHP-Welt verholfen: Es ist das Fundament unter vielen anderen Systemen. Das Redaktionssystem Drupal baut darauf auf, das Shopsystem Shopware ebenso, und selbst Laravel, der größte Konkurrent, nutzt mehrere Symfony-Komponenten. Wer PHP-Software einsetzt, nutzt mit einiger Wahrscheinlichkeit Symfony, ohne es zu wissen.

So sieht ein Ausschnitt aus einer Symfony-Anwendung aus, hier eine Route, die eine Rechnung als Daten für eine Oberfläche liefert:

Im Kern verarbeitet Symfony Anfragen nach einem klaren Muster: Eine Adresse kommt herein, das Routing findet den zuständigen Controller, der ruft Dienste auf und gibt eine Antwort zurück. Die Dienste, also die eigentliche Logik, verwaltet ein Container, der jedem Baustein automatisch das reicht, was er braucht. Das klingt technisch, bewirkt aber etwas sehr Praktisches: Die Fachlogik liegt in eigenständigen, testbaren Klassen, unabhängig von Oberfläche und Datenbank.

Genau diese Trennung ist der Grund, warum Symfony bei komplexer Fachlogik glänzt. Eine Preisberechnung mit Kundengruppen, Staffeln, Rahmenverträgen und Ausnahmen liegt als eigener Teil der Anwendung vor. Shop, Innendienst und Kundenportal rufen dieselbe Berechnung auf, statt sie dreimal nachzubauen, und ein automatischer Test prüft sie bei jeder Änderung. Ändert sich eine Vertragsregel, wird sie an einer Stelle geändert und überall wirksam.

Der zweite Pfeiler ist die planbare Pflege. Symfony nennt für jede Version im Voraus, wie lange sie unterstützt wird: Alle zwei Jahre erscheint eine Fassung mit langer Unterstützung, üblicherweise mit drei Jahren Fehlerbehebung und vier Jahren Sicherheitsaktualisierungen. Für den Betrieb einer Anwendung, die zehn Jahre leben soll, ist dieser Kalender mehr wert als jedes Feature.

Symfony ist zu Hause, wo Software eigene Regeln abbildet und lange lebt. Typische Einsatzgebiete sind:

• Fachanwendungen mit eigener Logik, etwa Preisfindung, Genehmigungswege oder Prüfvorschriften
• Webanwendungen, die über viele Jahre gepflegt und erweitert werden
• Schnittstellen, die mehrere Systeme mit derselben Geschäftslogik versorgen
• Erweiterungen für Systeme, die auf Symfony aufbauen, allen voran Shopware 6
• Einzelne Komponenten in fremden Projekten, vom Formular bis zur Konsole

Bei uns kommt Symfony dann ins Spiel, wenn die Fachlogik das eigentliche Produkt ist oder das Umfeld es nahelegt, etwa bei Onlineshops auf Shopware-Basis, deren Erweiterungen denselben Mustern folgen. Für die überschaubare Verwaltungsanwendung greifen wir dagegen häufiger zu Laravel, das schneller am Ziel ist. Diese Ehrlichkeit gehört zur Beratung dazu.

Symfony ist der Veteran unter den PHP-Frameworks. Die französische Agentur SensioLabs um Fabien Potencier entwickelte es zunächst für eigene Kundenprojekte und veröffentlichte es 2005 als freie Software. Den entscheidenden Schnitt brachte 2011 die komplett neu geschriebene Version 2: Aus dem Framework wurde eine Sammlung eigenständiger Komponenten, und genau diese Entscheidung machte Symfony zum Fundament der halben PHP-Welt. Bis heute steuert Potencier das Projekt, getragen von einer der größten Communities im PHP-Umfeld.

Die Freiheit von Symfony ist zugleich seine größte Hürde. Wer es einsetzt, sollte diese Punkte kennen:

• Der Start kostet mehr: Symfony verlangt Entscheidungen, die andere Frameworks längst getroffen haben, und das bezahlt man bei kleinen Projekten ohne Gegenwert
• Die Lernkurve ist steiler: Konzepte wie der Dienste-Container wollen verstanden sein, bevor die Arbeit flüssig wird
• Für Oberflächen, die sich laufend ohne Neuladen ändern, braucht es zusätzlich eine JavaScript-Schicht, Symfony liefert dann die Schnittstelle dahinter
• Für reine Inhaltsseiten ist es das falsche Werkzeug, dort ist ein Redaktionssystem der kürzere Weg

Kurz gesagt: Symfony belohnt Projekte, die seine Gründlichkeit brauchen, und bestraft Projekte, die sie nicht brauchen. Die Kunst liegt darin, vorher ehrlich zu unterscheiden.

Wer bei dieser Frage angekommen ist, hat die wichtigste Entscheidung meist schon getroffen: PHP ist gesetzt. Jetzt geht es um den Charakter des Projekts, und dafür hilft ein anderer Blick als der übliche Feature-Vergleich. Fragt euch, was in fünf Jahren das größere Risiko wäre:

• Wenn das Risiko lautet, dass die Anwendung zu langsam entsteht und zu viel kostet, spricht das für Laravel mit seinen fertigen Bausteinen
• Wenn das Risiko lautet, dass komplexe Fachregeln im Framework-Schema verbogen werden, spricht das für Symfony und seine Trennung von Logik und Rahmen
• Wenn der Betrieb über viele Jahre planbar sein muss, punktet Symfony mit angekündigten Wartungszeiträumen
• Wenn ihr bereits Shopware oder Drupal einsetzt, ist Symfony ohnehin schon im Haus und die Muster sind vertraut

Feindliche Lager sind das nicht: Laravel baut auf Symfony-Komponenten auf, beide sind ausgereift, beide werden lange gepflegt. Im Mittelstand ist Laravel häufiger die wirtschaftliche Wahl, aber sobald die Fachlogik das Geschäft trägt, dreht sich das Bild. Wie wir im Einzelfall entscheiden, steht auf unserer Seite zur Symfony-Entwicklung.

Für Auftraggeber ist Symfony vor allem ein Versprechen an die Zukunft. Die angekündigten Wartungszeiträume machen aus der Frage, wann die nächste große Aktualisierung fällig ist, einen Kalendereintrag statt einer Überraschung. Das erlaubt ehrliche Betriebskosten über Jahre, und genau daran scheitern viele Individualprojekte sonst. Dazu kommt die Testbarkeit: Fachlogik, die als eigener Baustein vorliegt, lässt sich automatisch prüfen, und das senkt die Kosten jeder späteren Änderung.

Auf der anderen Seite steht der höhere Einstiegspreis. Ein Symfony-Projekt braucht am Anfang mehr Konzept und mehr erfahrene Entwickler als ein Laravel-Projekt gleicher Größe. Beim Dienstleisterwechsel hilft dagegen wieder die Verbreitung: Symfony-Kenntnisse sind in der PHP-Welt Standardwissen, und weil das Framework klare Konventionen hat, findet sich ein neues Team in einem sauber gebauten Projekt gut zurecht. Fragt einen Anbieter ruhig, warum er Symfony statt etwas anderem vorschlägt. Die Antwort zeigt schnell, ob er euer Projekt oder sein Lieblingswerkzeug im Kopf hat.

Nach zwanzig Jahren ist die Frage berechtigt, und die Antwort fällt eindeutig aus: ja. Symfony ist nicht trotz seines Alters relevant, sondern wegen der Rolle, die es sich damit erarbeitet hat. Es steckt als Fundament in Drupal, Shopware und Teilen von Laravel, und solange diese Systeme leben, wird Symfony gepflegt. Ein Framework mit dieser Verankerung verschwindet nicht, es altert höchstens in Würde.

Die Entwicklung steht dabei nicht still: Jedes Jahr erscheinen neue Versionen, die Werkzeuge für moderne Oberflächen und Schnittstellen wachsen mit. Wer heute eine Fachanwendung in PHP plant, die 2035 noch laufen soll, macht mit Symfony keinen Fehler. Und wer noch grundsätzlicher vergleichen will, etwa mit der JavaScript-Welt rund um Node.js und NestJS, findet in dieser Artikelserie die passenden Gegenstücke.