Freitag, 6. Februar 2009

2 Wochen CakePHP

Nach 2 Wochen arbeiten mit CakePHP hier eine kurze Bilanz. Im Grossen und Ganzen versucht CakePHP die Ideen und Konzepte von Rails zu übernehmen, was auch in vielen Teilen des Frameworks gelingt.
Der grösste Kompromiss den CakePHP einging, ist auf PHP4 statt gleich auf PHP5 zu setzten. Dies hat leider weitreichende Konsequenzen:

Das beginnt schont bei ganz einfachen Sachen, wie etwa dass CakePHP kein Exception Handling kennt. Stattdessen werden E_USER_WARININGs und dergleichen ausgelöst.

Der grösste Unterschied zu Rails besteht jedoch in der Implementierung von ActiveReocrd. Das AR-Objekt wird in erster Linie als SQL Generator eingesetzt, die 'find' und 'read' Mehtoden geben keine Objekte zurück, sondern tief verschachtelte Arrays. Die Implementierung von CakePHP erinnert daher mehr an ein Table Data Gateway Pattern. Auch in CakePHP kennt Active Record die bekannten Callbacks wie 'beforeSave', aber auch hier wird mit Arrays gearbeitet, nicht mit Objekten.
Eine weitere Konsequenz daraus ist das CakePHP kein Single Table Inheritance oder deren polymorphe Variante kennt.

Zusammendfassend lässt sich aus meinen ersten Erfahrungen sagen, dass das Erarbeiten von Business Domain Objects in CakePHP wesentlich schwieriger fällt als in Rails. Das Active Record von CakePHP ist darauf ausgerichtet aus der Datenbank zu lesen und schreiben und die gewonnen Daten gleich auszugeben. Die Business Logik sollte gemäss dem Motto 'fat model, skinny controller' in die Model-Objekte abwandern, dies ist aber genau die Schwierigkeit, wenn diese mehrheitlich nur als Arrays daher kommen.
Trotzdem ist CakePHP eine gute Alternative, wenn man an PHP gebunden ist (oder wird). Zudem bieten heute alle Provider PHP, wer für ein einfaches Projekt einen billigen Host braucht ist CakePHP sicherlich eine Option. Für komplexere Projekte lohnt sich Ruby zu erlernen und auf ein durchgehend objekt-orientiertes Framework wie Rails zu setzten.

Keine Kommentare: