// der php hacker

// archiv

Conventions over configuration

Geschrieben am 13. Feb 2009 von Cem Derin

Derzeit lese ich Agile Webdevelopment with Rails. Das Buch ist zwar von 2006, aber mir ging es auch in erster Linie um das Prinzip von Ruby on Rails. Wie dem auch sei, keine Sorge, ich werde jetzt nicht über Ruby berichten oder gar komplett auf Ruby umsteigen (obwohl ich gerne was produktives mit Rails bauen würde, hehe). Es geht mir viel mehr um eines des Kernprinzipien von Ruby on Rails: Conventions over configuration.

Dieses Grundprinzip ist das, was Ruby eigentlich so bekannt gemacht hat. Was dafür gesorgt hat, dass man eine Applikation mit Rails in wenigen Minuten aufbauen kann (Scaffolding) und nur noch der Feinschliff gemacht werden muss. Aber was bedeutet conventions over configuration genau und wie kann man es auf PHP anwenden?

Ruby abstrahiert bei der Webentwicklung ständig auftretende Probleme und löst diese Eiheitlich. Auf eine MVC-Struktur bezogen hätten wir folgenden Fall: Wie haben es ständig mit Modellen zu tun, die eigene Controller bekommen. Diese Modelle werden in der Datenbank gespeichert und sollen über den controller aufgelistet, angelegt und einzeln editiert werden können. Statt das also für jedes Modell immer und immer wieder von Hand zu machen, gibt es in Rails ein Script, dem man den Namen und die Properties für das Model übergibt und das alles selbst anlegt.

Hierbei kommt dann obiges Prinzip zum Einsatz: Convetions over configuration. Statt also in der Modellklasse anzugeben, in welcher Tabelle die Daten für dieses Modell liegen (configuration), nimmt die Modellklasse an, dass die Daten in einer Tabelle liegen, die dem Plural des Modells entspricht (convention). Das Modell “article” wird seine Daten also in der Tabelle “articles” finden.

Dieses Prinzip setzt sich natürlich weiter fort. Ich möchte gar nicht weiter auf das konkrete Rails-Beispiel eingehen. Ich habe das Buch noch gar nicht zuende gelesen und laufe Gefahr, hier Lösungen für Probleme vorzuschlagen, die Rails wesentlich besser gelöst hat. Viel interessanter ist die Frage: Wie führe ich das in PHP ein?

Obiges Beispiel ist noch sehr einfach. Die Umsetzung sollte jeder, der seine Brötchen mit PHP verdient hinbekommen. Es gibt aber meiner Meinung nach eine ganze Reihe von Fällen, in denen solche Konventionen abgelehnt werden, da sie die Applikation ihrer Flexibilität rauben: Prominentes Beispiel sind Benamungen von Tabellenspalten in Datenbanken. In der Vergangenheit musste ich häufiger erleben, dass eine Benamung von Fremdschlüsseln im Sinne von “<zieltabelle>_<zielfeld>” zzgl. evtl. führender Zieldatenbank abgelehnt wurde. Konkrete Argumente fehlten oder beruhten auf mythischen “Ich meine mal gehört zu haben … ” und “da hatte ich mal Probleme mit, die ich jetzt aber nicht mehr erklären kann … ” Argumenten.

Ich sehe leider auch immer wieder, dass Methodenparameter so angeordnet sind, dass man um häufig genutzte Parameter zu erreichen andere übergeben muss, obwohl diese sich selten Ändern oder ermittelbar wären. Um das zu vermeiden, wird hier dann häufiger auf ein Array zurückgegriffen, in dem nur die Parameter, die man setzen will übergeben werden. Das ist augenscheinlich eine gute Lösung, leider kann einem die IDE dann keine Unterstützung mehr bzgl. der Typen oder generell der DocSyntax mitgeben. Sinnvoller wäre hier aber, dass man so wenig Parameter wie möglich übergeben muss. Lediglich wenn etwas mal nicht mehr der Konvetion entspricht, sollte man auf Konfiguration zurückgreifen.

Das beißt sich jetzt auch alles ein bisschen mit Nils’ Assert Null Artikel ;-)


#001
13. Feb 2009
Nils

Naja wirklich beißen tut sich da nichts. Obwohl du recht hast, ein wirklicher Fan von arrays als Parametern bin ich wirklich nicht. Dafür liebe ich meine IDE zu sehr.

// kommentieren

// senden
theme von mir, software von wordpress, grid von 960 grid system. funktioniert in allen browsern, aber der safari bekommt das mit der schrift am schönsten hin.