Für die Neuprogrammierung von Musik-Sammler.de soll mir ein bestehendes Open Source PHP Framework das meiste an Basisarbeit abnehmen, um gleich von Anfang an einiges an Zeit zu sparen. Also eine Implementierung des MVC-Patterns, eingebaute Mechanismen für das Loggen von Daten und der Behandlung von Fehlern usw. Außerdem hab ich auch die Schnauze voll, jede kleine und große Abfrage in der Datenbank irgendwo im PHP-Code zu verstreuen und jeden Query per Hand zu formulieren. Also wäre ein Datenbank-Wrapper bzw. ORM-Modul nötig. In dieser Hinsicht wurde ich aber dankenswerterweise von einem Arbeitskollegen bereits auf Doctrine aufmerksam gemacht. Den Namen hatte ich zwar schon früher gehört, hatte das aber irgendwie immer auch für eine Art Framework oder CMS-System gehalten. Nach einer Stunde kleinerer Experimente mit Doctrine bin ich aber schwer begeistert von diesem Tool. Abfragen und Ausgaben, wo ich inkl. der Queries 10 bis 20 Zeilen brauchte, ließen sich dank Doctrine auf zwei oder drei Zeilen reduzieren. Zwar ist dafür etwas Vorarbeit nötig, z.B. das Festlegen in PHP-Klassen, welche Datenbanktabelle in welcher Relation mit anderen steht, aber wenn man das erst mal stehen hat flutscht alles von selbst. Die Frage mit der Datenbankanbindung ist somit geklärt.

Etwas unsicher bin ich mir noch, was die Ausgabe der HTML-Seiten angeht. Momentan benutze ich die Template-Enginge Smarty, die auch eigentlich ihren Dienst gut verrichtet. Smarty ist aber irgendwo nochmals eine Schicht mehr im System, denn genausogut kann man Templates auch direkt per HTML und PHP erstellen. Allerdings stört mich dabei immer die Vermischung von HTML-Code und PHP-Code, ständig die öffnenden und schließenden PHP-Tags zu schreiben etc. Smarty macht zwar im Hintergrund im Endeffekt nichts anderes, aber irgendwo empfinde ich die Nutzung von Smarty bei der Erstellung der Tags etwas übersichtlicher. Allerdings müsste man Smarty, ganz wie Doctrine, auch erstmal in ein Framework eingebunden bekommen, weil viele Frameworks ihre eigenen Template-Logiken mitbringen. Zumal Smarty in der derzeitigen stabilen Version zum größten Teil noch in PHP 4 geschrieben wurde, ich möchte aber ausschließlich reine PHP 5 Softwarepakete benutzen. Zwar ist mit der Version 3 eine reine PHP 5 Version in der Entwicklung, aber die befindet sich derzeit noch im Beta-Stadium. Naja, mal schauen. Was das angeht, bin ich also noch etwas unentschieden.

Jetzt bleibt aber immer noch das wichtigste: das Framework was Doctrine und evtl. Smarty einbinden muss und alles miteinander in Verbindung bringt. Das Zend Framework kenne ich seit seinem ersten Release (wenn auch nicht bis ins letzte Detail) und das kann auch eine ganze Menge, aber das ist mir eigentlich viel zu aufgeblasen und ohne weitere Eingriffe nicht wirklich das mit der allerbesten Performance. Außerdem bringt es unzählige Komponenten mit sich, die ich zum größten Teil nie brauchen werde. Diverse andere bekannte Frameworks wie CakePHP, Symfony oder CodeIgniter sagen mir aus diversen Gründen ebenso nicht zu. Entweder sind sie mir zu groß dimensioniert, schneiden in Benchmarks nicht dolle ab oder funktionieren über einen Weg, der mir persönlich nicht so zusagt. Zum Beispiel mag ich sogenannte „Rapid Development“ Frameworks überhaupt nicht, da die immer dann Probleme bereiten, wenn man mal gezwungen ist einen Weg zu gehen, der von den Vorgaben des Frameworks abweicht.

Nach diversen Recherchen und Tipps sind jetzt zwei relativ junge Frameworks in der engeren Auswahl: die Version 3 von Kohana (auch wenn das ursprünglich mal von CodeIgniter abgeleitet wurde) und DooPHP. Beide haben ein relativ überschaubares, aber ausreichendes Set an Features, die Verwendung der Frameworks sieht auch nicht allzu kompliziert aus und sie funktionieren im großen und ganzen so wie ich es von einem Framework erwarte. Ein einfaches „Hello World“ war in beiden Frameworks nach den Tutorials auf den Webseiten (Kohana / DooPHP) schnell gemacht. Welches also nehmen?

DooPHP wirbt damit, eins der schnellsten, wenn nicht DAS schnellste Framework unter allen zu sein. Kohana bringt dafür mehr eingebaute Module mit, wie man bei einem Vergleich der API-Dokumentationen relativ schnell feststellen kann. Auch scheint Kohana momentan die Nase vorn zu haben, was die Verbreitung angeht. Und damit natürlich auch einer entsprechenden Community im Hintergrund. Von der teils seltsam anmutenden Homepage von Kohana 3 sollte man sich nicht irritieren lassen, die befindet sich noch in einem Beta-Stadium.

Was die Geschwindigkeit angeht, habe ich mal einfach die beiden „Hello World“ Skripte genommen und per Apache Benchmark miteinander verglichen. Beide Skripte machen nicht viel, außer einem Template die Nachricht „Hello World!“ zuzuweisen und auszugeben. Dabei wurden auch noch die internen Template-Funktionen genutzt, Smarty ist hier also nicht im Spiel. Speziell zu DooPHP sei noch angemerkt, dass ich das automatische Routing aktiviert habe. Ich bin faul und habe keine Lust jede in Frage kommende Route in der „routes.conf.php“ abzulegen. Für die Benchmarks lagen die Frameworks in je einem Unterverzeichnis online auf dem Musik-Sammler.de Server. Bei je 50 Aufrufen á 10 Aufrufe gleichzeitig (Parameter: -n50 -c10) der Seiten ermittelte Apache Benchmark folgendes (mehr Request/Sekunde = besser):

• DooPHP 1.2: 57,14 Requests/Sekunde
• Kohana 3: 56:14 Requests/Sekunde

Das erste, wenn auch nicht wirklich aussagekräftige „Duell“ gewann somit DooPHP mit minimalstem, nicht unbedingt nennenswertem Abstand. Allerdings muss man auch berücksichtigen, dass hier fast nichts an Dynamik in den Skripten drin war. Es wurden keinerlei Datenbankverbindungen aufgebaut, Sessions initialisiert oder sonstiges. Eine kleine Unterstützung fand bei beiden durch den Opcode-Cache APC statt, der für etwas zusätzliche Performance sorgt. Das Werben von DooPHP, das schnellste unter den Frameworks zu sein, konnte hier also schon mal nur unzureichend Bestätigung finden. Ein einfaches „Hello World“ ist als Benchmark aber kein wirklich ausreichendes Kriterium. Man misst bestenfalls, wie gut die Frameworks in ihren Kernfunktionalitäten wie das Routing usw. abschneiden. Eine Entscheidung kann erst wirklich getroffen werden, wenn man sich in beide Frameworks ein klein wenig mehr eingearbeitet hat.