Vorheriger Artikel Nächster Artikel

FLOW3 vs. Symfony2: Kampf der Giganten

Aus dem
t3n Magazin Nr. 27

03/2012 - 05/2012

FLOW3 vs. Symfony2: Kampf der Giganten

Mit hat im Oktober 2011 ein neues PHP-Framework das Licht der Welt erblickt. Zusammen mit Symfony2 buhlt es um die Gunst der PHP-Entwickler. Wir lassen zwei Kernentwickler aus den beiden Projekten zu Wort kommen – mit Plädoyers für „ihr“ Projekt.

PHP-Frameworks sind besser als ihr Ruf. Zumindest heute, da sein Stigma als „Skript-Kiddy-Sprache“ abgelegt hat. Die modernen Baukästen sind schlank, objektorientiert und setzen auf moderne Konzepte wie Model-View-Controller (MVC), Dependency Injection (DI), Domain-Driven Design (DDD) und Object-Relational Mapping (ORM). Doch welches Framework passt zu welchem Projekt?

Es gibt viele Gründe für und gegen ein bestimmtes PHP-Framework. Setzt eine Agentur auf ein Standardprodukt, ist die Entscheidung bereits gefallen: Die Mitarbeiter kennen sich damit aus und es gibt viel wiederverwendbaren Code. Der große Nachteil einer solchen Konstellation ist das an ein Framework gebundene Know-how. Wird das Projekt nicht mehr gepflegt, muss die Agentur selbst ran.

Ein weiterer Grund für oder gegen ein Framework kann der Kunde sein. Hat dieser konkrete Vorstellungen? Wie sieht das Anforderungsprofil aus – Umfang des Projekts, technische Gegebenheiten, Integration bestehender Systeme?

Zu guter Letzt: Welche Kompetenz bringen die Entwickler mit? Sind diese festgefahren mit einem Produkt? Auf welche Community kann man dank zahlreicher Kontakte im Notfall zurückgreifen? Und wie umfangreich und gut ist die Dokumentation?

Auf der Suche nach einem PHP-Framework stößt man unweigerlich auf Symfony2 und FLOW3. Beide gelten als äußerst durchdacht und können – FLOW3 zumindest über den Umweg TYPO3 – auf eine starke Community verweisen. Um Agenturen und Entwicklern die Entscheidung zu erleichtern, lässt t3n die Entwickler – Karsten Dambekalns für FLOW3 und Lukas Kahwe Smith für Symfony2 – selbst zu Wort kommen.

FLOW3 – von Karsten Dambekalns

FLOW3 wurde nicht mit dem Ziel entwickelt, ein Framework zu programmieren – ein gutes Framework braucht ein anderes Ziel als sich selbst. Es entstand aus den Anforderungen und Wünschen der Entwickler an die Basis der neuen TYPO3-Version. Entsprechend standen zu Beginn die Suche nach all jenen Vor- und Nachteilen, die andere Frameworks bereits mitbringen, sowie das Lesen von Fachliteratur zu Domain-Driven Design, Enterprise Application Architecture, TDD und sauberem Code auf dem Programm.

So entstand aus der Erkenntnis, dass es noch keine für uns optimale Lösung gibt, die Basis für das nächste TYPO3. Zudem wuchs die Erkenntnis, dass diese Basis zu jedem PHP-Projekt passen könnte, die Veröffentlichung als Framework also sinnvoll ist. In der Folge wuchs das Team auf ein gutes Dutzend Entwickler.

Mit der wachsenden Größe des Teams halfen agile Entwicklungs- (Extreme Programming, XP) und Management-Modelle (Scrum, Kanban) dabei, auch die Software-Qualität zu fördern: Test-Driven Development (TDD), Code Review und Continuous Integration (CI) haben sich bei uns bewährt, wurden teilweise ins TYPO3-Projekt übernommen und sollten in Projekten heute Standard sein.

FLOW3 ist zwar verhältnismäßig jung, kann aber dank des TYPO3-Projekts im Hintergrund auf eine starke und große Community verweisen.
FLOW3 ist zwar verhältnismäßig jung, kann aber dank des TYPO3-Projekts im Hintergrund auf eine starke und große Community verweisen.

FLOW3 ist dabei breit aufgestellt – nicht nur, was die Entwicklung angeht: Git sowie das Code-Review-System Gerrit, Jenkins als CI-Server zum automatisierten Ausführen der Tests und für das Deployment von

Projekten auf Integrations- und Live-Servern gehören ebenso zum Repertoire wie tägliche Online-Meetings. Letztere helfen vor allem dabei, die Kern-Konzepte von Scrum auf ein geografisch verteiltes Team zu verteilen.

Sauberer Code, klare Ziele

Die Qualität von Software kann auf vielfältige Art beurteilt werden. Die Lesbarkeit des Quellcodes gehört aber unbedingt dazu. Denn wenn bei einer Bibliothek, einer Applikation oder einer anderen Software auch nur die geringste Chance besteht, dass ich es verändern, verbessern oder integrieren will, muss ich mich im Quellcode wohlfühlen. Nur wenn der Quellcode lesbar ist und gut aussieht, kann man mit Freude an und mit ihm arbeiten.

Im FLOW3-Projekt genießen Coding Guidelines (CGL) deshalb eine sehr hohe Priorität. Darüber hat sich noch niemand beschwert – im Gegenteil, die allermeisten Patches folgen bereits zu Beginn den Regeln. Und das verwundert nicht, denn das Wichtigste ist auf einer Seite zusammengefasst und der bestehende Code geht mit gutem Beispiel voran.

Neben dem rein „visuellen“ Programmierstil gibt es jedoch eine weitere, noch wichtigere, Komponente: den „semantischen“ Stil. Nur wenn Klassen, Methoden und Variablen aussagekräftige Namen haben, erschließt sich der Code sofort. Abkürzungen haben in der Welt von FLOW3 keinen Platz, Konsistenz geht vor Kreativität. Nur dann ist es möglich, intuitiv zu arbeiten – ohne zu Überlegen, ob es nun getEnv() oder getEnvironment() heißt.

Ein Framework, kein Baukasten

Die Abgrenzung von FLOW3 zu Apache Zeta Components (ehemals ezComponents) und dem Zend Framework ist einfach: Zeta und Zend sind Sammlungen von Komponenten. Wie in Perl gibt es mehr als einen Weg zur Lösung. Gerade für Einsteiger kann dies eine große Hürde sein. Wird nur eine einzelne Komponente benötigt, können diese Projekt eine gute Lösung bieten. Soll jedoch eine Applikation von Grund auf damit entwickelt werden, hat man die Qual der Wahl – und bekommt am Ende eine Lösung, die sich genau soviel von allem anderen unterscheidet, dass die üblichen Problemlösungen nicht weiterhelfen.

Wer einen ganzheitlichen Ansatz sucht, ist jedoch auch bei anderen Frameworks nicht am Ziel. Meist muss der Kern für ein neues Projekt um zusätzliche Komponenten erweitert werden – schon gibt es wieder die Qual der Wahl und mehrere Wege, Benutzer einzuloggen oder REST zu unterstützen.

FLOW3 verfolgt als Applikations-Framework einen anderen Ansatz: Wirklich wichtige Komponenten werden mitgeliefert, Konvention geht vor Konfiguration. Zudem entfällt die Entscheidung zwischen XML, PHP und YAML – es gibt nur YAML. Der Dependency-Injection-Container wird nicht mit XML konfiguriert, sondern ist durch Auto-Wiring nahezu wartungsfrei. Policies regeln Zugriffsbeschränkungen auf Methoden und Daten zentral.

Erweiterbarkeit und Integration

Jedes Framework ist nur so gut, wie die zusätzlichen Möglichkeiten, die es bietet. FLOW3 ist noch jung und wird, TYPO3 hat es vorgemacht, in Zukunft sicher eine Menge Erweiterungen bekommen. Das FLOW3 Package Repository nimmt in der Planung bereits konkrete Züge an und wird sich viel von verteilter Versionskontrolle abschauen.

Um aber nicht ständig das Rad neu erfinden zu müssen, kann FLOW3 künftig jede PSR-0-konforme Erweiterung unverändert als Package nutzen. Zudem ist die direkte Nutzung von Komponenten aus Zend und Symfony geplant.

Das konsequente Entwickeln gegen Interfaces in FLOW3 ermöglicht es, viele Komponenten gegen eigene Implementierungen zu tauschen sowie neue hinzuzufügen. Es fehlt das passende Logging- oder Caching-Backend? Kein Problem. Das CouchDB-Paket für FLOW3 zeigt, dass auch grundlegende Dinge angepasst werden können. Auch ein SOAP-Controller und die Zusammenarbeit mit dem Solr-Projekt sind bereits erfolgreich im Einsatz.

Und die eigentliche Business-Logik? Durch den Fokus auf Domain-Driven Design, die Nutzung der daraus resultierenden Konzepte für die Datenspeicherung und die „automatische“ Dependency Injection, ist der Code, der die eigentliche Funktionalität umsetzt, vom Framework so unabhängig wie möglich. Bereits in PHP umgesetzte Prozesse lassen sich mit relativ geringem Aufwand in FLOW3 nutzen und umgekehrt FLOW3-basierte Applikationen in anderem Umfeld weiterentwickeln.

Geschwindigkeit

Traditionell wird der Geschwindigkeitskampf über Benchmarks ausgetragen, diese sind jedoch in den meisten Fällen für das reale Projekt nur wenig hilfreich. Die Laufzeit-Performance eines Projekts kann durch Caching und Skalierung (fast) immer in Bereiche gehoben werden, die für das Projekt ausreichen. Viel wichtiger ist doch, was im Projektalltag passiert. Wie schnell kann ein neuer Entwickler den Code verstehen? Wie lange dauert es, eine neue Version auf den Live-Server zu bringen? Wie kostspielig ist ein Update des Frameworks?

FLOW3 wird mit einem starken Usability-Fokus entwickelt. Der Entwickler soll möglichst wenig tippen müssen und trotzdem intuitiv arbeiten können. Konfiguration soll überflüssig sein, wo dies durch sinnvolle Konventionen möglich ist. Dies ermöglicht schnelle Entwicklung auch nach dem Scaffolding und vereinfacht die Wartung. Updates sind sauber dokumentiert und für notwendige Anpassungen am Projekt stellt FLOW3 Tools wie „Surf“ bereit.

Community und Verbreitung

FLOW3 liegt, was die Verbreitung und die Größe der Community angeht, aufgrund seines jungen Alters weit hinter anderen Frameworks zurück. Das Potenzial ist jedoch enorm, wenn man die TYPO3-Community betrachtet. Die Rückendeckung durch das TYPO3-Projekt und die bereits jetzt stetig wachsende Community mit Usergroups in ganz Deutschland geben hier die Richtung vor.

Auch die Tatsache, dass bereits ein halbes Jahr nach dem ersten Relase eine Handvoll Unternehmen das Framework für kostspielige Projekte bis hin zur zentralen Verwaltung aller Kundendaten nutzen, zeigt, wie belastbar das Framework ist. Und es zeigt, welches Vertrauen man in FLOW3 setzen kann.

Der Autor

Karsten Dambekalns lebt mit seiner Frau Līga, drei Kindern und einer namenlosen Kaffeemaschine in Lübeck. Zwei Jahre nach dem Erstkontakt mit TYPO3 stieg er bei der T3BOARD04 erstmals auf die Bretter und beschäftigte sich mit der Umsetzung des DBAL-Projekts. Seit 2005 ist er Kernentwickler des CMS, bis 2012 war er im Steering Committee der TYPO3-Association. Seit 2008 arbeitet er ausschließlich an TYPO3 Phoenix.

SYMFONY2 – von Lukas Kahwe Smith

Wieso man sich Symfony2 genauer anschauen sollte, fragte ich per Twitter. Schnell kam eine Antwort: „Einfach den Quellcode zeigen, dann sollte alles klar sein.“ Stimmt, denn es gibt nur wenige PHP-Projekte von ähnlicher Größe, die sowohl in Design, Architektur und Konsistenz mithalten können.

Noch schneller erhält man einen Überblick, wenn man direkt zur Entwicklungsquelle surft, dem Symfony2-Github-Repository. Die detaillierten Code-Reviews der Community jedes Pull-Requests zeigen, dass das Resultat unweigerlich zu hoher Qualität gelangt.

An der Spitze dieser Community sitzt Fabien Potencier, ein Perfektionist, der in Sachen Produktivität seinesgleichen sucht. Mit Github hat er das notwendige Werkzeug gefunden, die Community zum Zentrum der Entwicklung zu machen. Denn Github schafft jene Transparenz, die es ihm und allen Beteiligten zu jeder Zeit ermöglicht, den Prozess zu überblicken und zu beeinflussen.

Um es also klar zu sagen: Ohne Github gäbe es Symfony2 in dieser Form heute nicht. Und ohne Fabien Potencier gäbe es Symfony2 in dieser Form heute auch nicht. Aber ohne die Community würde Fabien, bei all seiner Produktivität, noch Jahre brauchen, um soweit zu sein wie wir heute schon sind.

Zahlen und Fakten

Symfony2 ist ein PHP-5.3-basiertes HTTP-Applikations-Framework (mehr dazu weiter später). Es übernimmt Konzepte vom Java Spring Framework, von Pythons Django sowie einer Vielzahl von anderen Frameworks. Quasi das Beste aus allen Welten. Im Kern liefert es über 20 Komponenten, die es ermöglichen sollen, eigene Domain-spezifische Frameworks entwickeln zu können. Daher sind auch alle Komponten eigenständig nutzbar. Um das Ganze auch in der Praxis zu testen, gibt es, ebenfalls aus der Feder von Fabien Potencier, das Micro-Framework Silex (siehe Artikel ab Seite 156). Inspiration hier war Rubys Sinatra.

Symfony2 setzt stark darauf, bewährte Lösungen anderer Frameworks zu übernehmen und kann damit eine hohe Qualität vorweisen.
Symfony2 setzt stark darauf, bewährte Lösungen anderer Frameworks zu übernehmen und kann damit eine hohe Qualität vorweisen.

Symfony2 setzt auf eine Vielzahl von Komponenten aus der Community. Darunter Twig, Swiftmailer, Doctrine, Assetic, Monolog und Composer. Und im näheren Umfeld von Symfony2 haben sich noch andere Komponenten entwickelt: Imagine, Buzz, Goutte, Jackalope, Behat und Mink. Das NIH-Syndrom (not invented here) gibt es also bei Symfony2 nicht.

Dabei sollte nicht unerwähnt bleiben, dass auch hier diverse der genannten Projekte Portierungen erfolgreicher Bibliotheken aus anderen Sprachen sind. So könnte man auch sagen, dass die Symfony2-Community das Konzept „Standing on the Shoulders of Giants“ voll und ganz verinnerlicht hat.

Diese Philosophie wird mittlerweile auch erfolgreich in andere Frameworks exportiert: So werden etwa die nächsten Versionen von phpBB und MidgardCMS Symfony2 nutzen, Drupal 8 hat bereits zwei Symfony2-Komponten integriert und evaluiert weitere.

Erweiterungen und Integration

Das Symfony2-Framework selbst ist über so genannte Bundles erweiterbar. Genauer gesagt ist das Framework selbst auch ein Bundle, genannt FrameworkBundle. Was dies verdeutlicht? Alles bei Symfony2 ist austausch- und erweiterbar, auch dank des Dependency-Injection-Containers. Über diesen registrieren alle Bundles eigene „Services“ samt ihren zugehörigen Abhängigkeiten.

Im inoffiziellen Bundle-Index knpbundles.org sind mittlerweile über 1000 Bundles gelistet und täglich kommen etwa fünf neue hinzu. Die Webseite bietet zudem einen Algorithmus, der aus den Nutzern, die das Projekt auf Github verfolgen, jenen, die sich an der Entwicklung beteiligen, den Unit-Tests auf Travis-CI.org und anderen Faktoren einen Wert bestimmt, der als Indikator eine Bewertung darüber abgibt, wie gut das Bundle in der Community akzeptiert ist.

Model, View, Controller?

Die Antwort auf die Frage, ob Symfony2 ein MVC-Framework ist? „Jein“. Denn Symfony2 kann genau soviel MVC wie all jene Frameworks, die ebenfalls meinen, MVC zu bieten. Ob nun Doctrine oder Propel als Model-Layer verwendet wird – der Fokus liegt bei Symfony2 auf „Separation of Concerns“; MVC ist in diesem Sinn also nur eine grobe Richtlinie auf dem Weg zu diesem Ziel.

Symfony2 enthält eine Reihe von überaus nützlichen Komponenten, um CLI-Kommandos zu entwickeln; primär jedoch konzentriert sich das Framework auf eine optimale Integration in die HTTP-Welt. So erreicht etwa der von einem Browser gesendete Request Symfony2 über den sogenannten Frontcontroller. Dieser besteht im Kern aus der Instanzierung eines Request-Objekts, welches an einen Kernel übergeben wird. Letzterer generiert aus dem Request eine Response und gibt diese in der Folge wieder an den Frontcontroller zurück.

Der Kernel durchläuft dabei vor und nach dem Aufrufen des Controllers eine Reihe von Standard-Events, welche als definierte Extensionpoints dienen. Die Response wiederum wird im Fontcontroller durch die „send()“-Methode ausgegeben und landet schließlich beim Browser. Ab Version 2.1 unterstützt Symfony hier zusätzlich optionales Response-Streaming.

Caching inklusive

Richtig spannend ist, dass man den Standard-Kernel durch einen Wrapper an HTTP-Caches übergeben kann. Falls Symfony2 dann erkennt, dass es sich hinter einem ESI-fähigen Reverse Proxy befindet, werden automatisch entsprechende Funktionen genutzt. So kann selbst eine stark dynamische Webseite zu großen Teilen zwischengespeichert werden.

Diese Arbeit verrichtet dann aber nicht der Webserver, sondern ein hoch optimierter Reverse Proxy, wie etwa Varnish. Das Seiten-Caching wird in Symfony2 also nicht neu erfunden, sondern es werden die Caching-Funktionen von HTTP wiederverwendet. Ach, und alle, die kein Varnish installieren können, bekommen mit Symfony2 einen in PHP implementierten Reverse Proxy gleich mitgeliefert.

Frontcontroller in Symfony2

<?php
require __DIR__.'/../app/autoload.php';
require __DIR__.'/../app/AppKernel.php';
//require __DIR__.'/../app/AppCache.php';
use Symfony\Component\HttpFoundation\Request;
$kernel = new AppKernel('prod', false);
//$kernel = new AppCache($kernel);
$request = Request::createFromGlobals();
$response = $kernel->handle($request);
$response->send();
$kernel->terminate($request, $response);

Listing 1

Wieder wird NIH durch das Konzept „Standing on the Shoulders of Giants“ ersetzt. Ein Weg, der in der Vergangenheit und der auch in Zukunft überzeugen wird.

Wer sich selbst überzeugen möchte, ist auf diesem Weg herzlich dazu eingeladen. Und wer sich überzeugt hat, der möge doch Fabien Potencier eine Postkarte schicken. Als Dank gibt es dafür dann ein Badge (http://t3n.me/SymfonyBadge).

Der Autor

Lukas Kahwe Smith arbeitet für die Liip AG in Zurich. Er ist seit über 10 Jahren in der PHP-Community aktiv und war unter anderem als Co-Release-Manager für PHP 5.3 tätig. Bei Symfony2 ist er von Beginn an dabei und arbeitet auch an einer Vielzahl von Bundles. Er gehört zudem zum Symfony2-CMF-Team und den Definierern des PHPCR-Standards sowie dessen Referenz-Implementierung Jackalope. Auch im Doctrine-Projekt hat er an einigen Stellen seine Finger im Spiel.

Abonniere jetzt t3n-News über WhatsApp und bleib mobil auf dem Laufenden!
t3n-News via WhatsApp!
Vorheriger Artikel Zurück zur Startseite Nächster Artikel
2 Antworten
  1. von Heinz Inge am 31.07.2012 (09:44 Uhr)

    Beide leiden unter demselben Problem, Vermüllung und unglaubliche Langsamkeit.
    Grade Flow3 kann ich leider nicht ernst nehmen weil es von denselben Leuten geschrieben wurde die es über viele Jahre nicht geschafft haben Typo3 benutzbar zu machen. (Und nein, nur weil viele T3 im Einsatz haben heisst es nicht das es auch benutzbar ist, es garantiert nur gute Einnahmen weil man Schulungen und teure Anpassungen verkaufen kann)

    Diese "Überstandardisierung" ekelt mich an. Man verbringt mittlerweile mehr Zeit damit Standards umzusetzen, Tests zu schreiben und das Caching zu verfeinern als die eigentliche Aufgabe zu erfüllen.

    99% der Webprojekte würden diesen Aufwand niemals rechtfertigen und sind schlicht "Overengineered".

    Ich habe dabei nichts gegen Frameworks an sich, aber sobald sie mehr Arbeit machen als sie Probleme lösen bzw ohne massives Caching gar nicht benutzbar sind verursachen sie ohne Zwang unnötige Kosten.

    Ich halte es lieber Frei nach dem Motto: "Frickelst du noch oder verdienst du schon?"

    Antworten Teilen
  2. von Martin am 31.07.2012 (12:29 Uhr)

    FLOW3 würde ich als ewigen Newcomer auch nicht gerade als "Gigant" bezeichnen...

    Antworten Teilen
Deine Meinung

Bitte melde dich an!

Du musst angemeldet sein, um einen Kommentar schreiben zu können.

Jetzt anmelden

Aktuelles aus dem Bereich PHP
PHP-Framework Flow in Version 3.0 erschienen - Das ist neu
PHP-Framework Flow in Version 3.0 erschienen - Das ist neu

Das PHP-Framework Flow ist in Version 3.0 erschienen. Wir geben euch eine Überblick über die Neuerungen. » weiterlesen

Getrennte Wege: Neos spaltet sich von TYPO3-Association ab
Getrennte Wege: Neos spaltet sich von TYPO3-Association ab

Das Neos-Team wird sich von der TYPO3-Association abspalten. Durch den Schritt soll sich das Team besser auf die eigene Produktstrategie konzentrieren können. » weiterlesen

WordPress, Joomla!, TYPO3 CMS und Co.: Die wichtigsten Updates für die wichtigsten CMS (November)
WordPress, Joomla!, TYPO3 CMS und Co.: Die wichtigsten Updates für die wichtigsten CMS (November)

Bei den großen CMS und einem Blog-System gibt es regelmäßig Updates, die neue Funktionen liefern oder Sicherheitslücken schließen. Die wichtigsten Updates aus dem Monat November stellen wir euch … » weiterlesen

Alle Hefte Jetzt abonnieren – für nur 35 €

Kennst Du schon unser t3n Magazin?