The Agavi Way

Frameworks für PHP5 gibt es wie Sand am Meer. Mehr oder weniger gut sollen sie dem Entwickler helfen, Probleme zu vereinfachen. Dabei treten aber erstmal welche auf: neue Datenbankschnittstelle, Platzierung des Codes unklar, standartisierte Lösungsansätze fehlen – dies sind nur einige Dinge auf die man bei der Benutzung stoßen wird.
Bei einem Vergleich sind wir dabei auf Agavi gestoßen, wiedermal ein Framework welches aus dem Frust über Mojavi3 entstanden ist. Es basiert auf dem MVC Paradigma und hat einen entscheidenen Vorteil: Es zwingt dazu sauberen Code zu schreiben. Außerdem wird einem nicht ein neues Datenbank- oder Templatesystem vorgesetzt. Eher hat man die Qual der Wahl: Propel oder Doctrine,  PHPTal oder normales PHP. Natürlich sind viel mehr Kombinationen möglich.
Agavi beschränkt sich also auf die Kerngeschäfte eines Frameworks und bietet dem Entwickler einen sinnvollen Baukasten mit folgenden Features an:

  • Configuration Management
  • MVC (Models, Views, Controllers)
  • Security
  • Routing und Speaking URL’s
  • Generischer Benutzer mit RBAC
  • Template (Renderer) Baukasten
  • Outputtypes (Web, Console, Soap, JSON)
  • Sessions und deren Storagependants
  • Logging
  • Validation (GET/POST)
  • I18N

Alle Bauteile sind durch abstrakte Klassen und Interfaces beschrieben was eine Erweiterung einfach gestaltet, außerdem wird das PHP5 Exception Modell konsequent durchgezogen. Durch Phing wird zusätzlich ein Buildtool mitgeliefert welches dem Entwickler ermöglich alle Komponenten der Software zu erstellen. Somit werden Stubs für Actions oder Models schnell erstellt.
Natürlich sind die klassischen Probleme der Einarbeitszeit noch vorhanden, die Lernkurve ist allerdings hoch – Und hat man sich den ‘Agavi Way’ angeeignet, geht alles weitere schnell von der Hand!

Marius Hein
Marius Hein
Head of Development

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert, dann als Application Developer gearbeitet und ist nun Leiter der Softwareentwicklung. Ausserdem ist er Mitglied im Icinga Team und verantwortet dort das Icinga Web.

Doctrine für PHP


Bei Datenbankverbindungen in PHP gehen die Meinungen der Entwickler schnell auseinander. Jeder verwendet die schnellste Lösung oder schreibt schnell eine Klasse welche die wichtigsten Funktionen übernimmt. Mittlerweile stehen dem Entwickler ja drei native Schnittstellen zur Verfügung: mysql, mysqli und PDO – wobei jede Vor- und Nachteile aufweist. Und es gibt eine Reihe von Abstraktionsschichten welche das Auslesen und Bearbeiten von Datensätzen erleichtern sollen wie z.B. ADODB, Creole/Jargon oder die Tools um MDB2 auf PEAR. Allerdings deckt keines dieser Werkzeuge den gesamten Bereich richtig ab. Schemadateien müssen von Hand erzeugt werden, Mapper von PHP Objekten sind umständlich zu konfigurieren, initialer Datenimport muss von Hand erledigt werden und komplizierte Abfrageteile werden dann doch wieder in SQL realisiert.
Seit 2006 wird an dem ORM Tool Doctrine geschraubt welches seit September in einer stabilen major release vorliegt. Doctrine orientiert sich an Hibernate aus der Javawelt und an den Active Record Pattern von Ruby on Rails. Das tolle ist: Man schreibt fast (!) keine einzige Zeile SQL mehr.
Die Relationen aus der Datenbank werden auf verschiedene Arten in PHP Objekte übersetzt. Man kann entweder gleich PHP Klassen schreiben (Aus denen dann später auch das Datenbankmodell erzeugt werden kann), lässt sich die Klassen aus einer bestehenden Datenbank erzeugen oder schreibt das Modell in einer deskriptiven, Doctrine eigenen Sprache welche auf YAML basiert. Es ist auch möglich verschiedene Datenbanken in einem logischen Modell zu Verbinden. Selbst solche Strukturen verhalten sich in PHP völlig transparent.
Doctrine an sich besteht aus einer Reihe von Objekten wie Connections, Tables, Collections, Records, Queries. Letztere können durch eine eigene, an SQL angelehnte Sprache, abgefragt werden (Anlehnung an HQL von Hibernate: DQL). Alle diese Objekte folgen speziefischen Entwurfsmustern wie Singletons, Prototypes oder EventListeners und können dadurch einfach erweiter werden.
Für kleinere Projekte schießt man damit sicherlich mit Kanonen auf Spatzen, auch benötigt man etwas Einarbeitszeit um den Baukasten zu verstehen. PHP geht damit aber insgesamt einen großen Schritt in Richtung Enterprisesoftware. Orientiert sich ein geplantes Projekt in diese Richtung ist Doctrine sicherlich nicht verkehrt und nimmt für die Zukunft eine Menge Arbeit ab: Cheatsheet von Doctrine.

Marius Hein
Marius Hein
Head of Development

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert, dann als Application Developer gearbeitet und ist nun Leiter der Softwareentwicklung. Ausserdem ist er Mitglied im Icinga Team und verantwortet dort das Icinga Web.