PHP Unconference in Hamburg

Veröffentlicht am 16. September 2009 (vor 177 Tagen)

Es ist immer wieder erstaunlich, was Freilwillige und Enthusiasten so alles auf die Beine stellen können. Das beginnt in Nordamerika mit der PHP Quebec, die im nächsten Jahr ConFoo heißen wird, und endet mit der PHP Unconference in Hamburg - zumindest, wenn man die Landkarte von links nach rechts und von oben nach unten liest und berücksichtigt, dass ich noch niemals eine PHP-Konferenz östlich oder südlich von Deutschland besucht habe.

Zur diesjährigen PHP Unconference Hamburg wurde an anderer Stelle bereits viel Gutes berichtet - ich will nichts von dem wiederholen, mich den positiven Reaktionen aber uneingeschränkt anschließen. Danke an Judith und das Orga-Team. Ihr wißt ja: nach dreimal ist es Tradition, jetzt habt Ihr die Pflicht, im nächsten Jahr wieder eine Unconference zu organisieren. Und das geht dann rekursiv so weiter.

Die Stimmung auf einer Unconference ist eigentlich immer sehr gut. Vielleicht liegt das daran, dass noch weniger finanzielle Interessen aller Beteiligten im Spiel sind als auf einer kommerziellen Konferenz. Vielleicht auch daran, dass viele einen Besuch auf der Unconference mit einem Wochenendausflug nach Hamburg verbinden und vor, während oder nach der Konferenz noch ein bißchen Sehenswertes erleben wollen. Das äußert sich dann so, dass einem manche Besucher schon Samstag früh angrinsen und sich über zu wenig Schlaf und Nachwirkungen des Vorabends beschweren. Oder auch so, dass manche Konferenzteilnehmer nach dem Besuch auf der Reeperbahn am nächsten Konferenztag gar nicht mehr gesehen wurden …

Mein einziger Kritikpunkt beziehungsweise Verbesserungswunsch zur Unconference betrifft weder Organisation noch Sponsoren, sondern das Publikum (und auch dies nur bezogen auf den nachfolgend ausgeführten Aspekt). Ganz abgesehen von einzelnen statistischen Ausreißern, die sich tatsächlich Samstag vormitag darüber beschwert hatten, die Konferenz sei unorganisiert, da noch nicht mal vorab ein Vortragsprogramm festgelegt worden sei, scheinen die allermeisten Teilnehmer das Unconference- beziehungsweise Barcamp-Prinzip verstanden zu haben. Ich glaube aber, wir alle können diese Prinzip noch besser leben. Ich würde mir mehr Interaktion, Fragen (gerne auch provokante oder vermeintlich “dumme”) und Diskussion wünschen, auch und gerade von den zahlreichen Teilnehmern, die nicht zu den “üblichen Verdächtigen” gehören. Wir “Verdächtigen” haben großen Spaß daran, eine Unconference inhaltlich mitzugestalten und allen “Unverdächtigen” möglichst viel mitzuteilen, wir lernen aber auch jedes Mal sehr viel von jedem einzelnen anderen Teilnehmern, durch jede Frage und jede Idee. Aber wir haben auch Spaß daran, uns mal zurückzulehnen und zu hören, wie “Unverdächtige” an ein Thema herangehen und was sie zu sagen haben.

Liebe (Un-)Konferenzteilnehmer: weniger Scheu, mehr Fragen. Sprecht uns einfach an. Ich kenne keinen “Verdächtigen” oder “Unverdächtigen”, der damit ein Problem hätte. Consulting während einer Konferenz ist kostenlos.

So wurde ich denn nach meinem Vortrag von zwei hübschen Damen angesprochen, deren Namen ich hier auch dann nicht nennen würde, wenn ich ihn mir hätte merken können (man schaut so schlecht auf das Namensschild, wenn man nebeneinander sitzt). Meinte die eine, die andere hätte eine Frage an mich, würde sich aber nicht trauen, sie zu stellen. War mein Support Animal Testing T-Shirt denn wirklich so furchteinflößend?

Die MVC-Session

Zu meiner Schande muss ich hier öffentlich eingestehen, dass ich es versäumt hatte, in meiner MVC-Session einen Protokollanten zu benennen. Das mag vielleicht auch daran liegen, dass es nicht mehr unbedingt zeitgemäß ist, einen Beamer mit 640×480-Auflösung betreiben zu müssen. Dankenswerterweise kam mir jemand vom Orga-Team zu Hilfe, so dass ich meine Folien (viele waren es ja nicht, da ich auch diskutieren wollte) dann doch noch hochbeamen konnte.

Ich will also versuchen, nachholen, was dank meiner Versäumnis nicht dokumentiert wurde, nämlich einen nach meiner Ansicht recht guten Vortrag. Gut deshalb, weil trotz Kris Köhntopp nebenan viele Zuhörer da waren und eine wirklich gute Diskussion entstanden ist. Wir haben (freiwillig, ich hatte das offizielle Ende bereits ausgerufen) bis weit in die Mittagspause diskutiert. Und danach trotzdem noch was zu essen bekommen, was wirklich nicht auf jeder Konferenz der Fall ist …

Mein Ziel war es, den Zuhörern, die MVC nicht oder nicht gut kennen, einen Einblick zu geben, was MVC im Webumfeld ist, und den Zuhörern, die meinen, MVC verstanden zu haben, zu zeigen, dass sie MVC eben doch noch nicht oder nicht richtig verstanden hatten. So geht es mir selbst zumindest immer wieder, und die zahlreichen on- und offline-Diskussionen über MVC zeigen, das ich damit beileibe nicht der einzige bin.

Nicht für das Web

MVC stammt aus den siebziger Jahren des letzten Jahrtausends, und ist daher per se nicht für das Web entwickelt worden. Das ursprüngliche Einsatzgebiet waren in Smalltalk geschriebene GUI-Anwendungen. Das Model sind dabei Daten, die in der Benutzeroberfläche durch einen oder mehrere Views dargestellt werden. Um redundante Datenhaltung zu vermeiden und unterschiedliche Belange zu trennen, hat man MVC entwickelt. Sieht man sie eine GUI-Anwendung an, gibt es oft identische Informationen, die an unterschiedlichen Stellen präsentiert werden, etwa die Maße eines Rechteckes in einem Zeichenprogramm und eine graphische Repräsentation dieses Rechteckes. Damit nun bei Änderungen keine Inkonsistenzen durch redundante Datenhaltung entstehen können, speichert man die Daten (im diesem Fall beispielsweise die Maße und die Position) im Model. Auch wenn es auf den ersten Blick so aussehen mag, hat das Model rein gar nichts mit Datenhaltung zu tun.

Ein View stellt etwas dar und ist klassisch ein Element der GUI. Zwischen View und Model vermittelt der Controller. Er nimmt Events vom View entgegen (geklickt, Fokus gesetzt/verloren etc.) und reagiert darauf mit einer Modifikation des Models. Nun benachrichtigt das Model den View, dass es eine Änderung gab und sich der View doch freundlicherweise aktualisieren sollte.

Im Web-Umfeld sieht das alles ganz anders aus. Hier haben wir eine Rechnergrenze zwischen der eigentlichen HTML-Darstellung, also dem Browser, und dem Server, auf dem unser PHP läuft. Client und Server sprechen miteinander, indem Textnachrichten ausgetauscht werden. In die eine Richtung sind das HTTP-Requests, in die andere Richtung HTML-Quelltexte (Varianten wie XML und so weiter ändern nichts am Grundprinzip, so dass wir die Betrachtungen zur Vereinfachung auf einen HTML-View beschränkt haben).

AJAX

Der Server bekommt von den Events im Browser erst mal gar nichts mit, außer man verknüpft jedes Event tatsächlich mit dem Senden eines HTTP-Requests. Das kann man zwar machen (und man nennt es dann oftmals AJAX), aber es ist nicht wirklich schnell, da wir im Prinzip den Browser zu einer Remote-GUI degradieren. X-Windows über ein langsames Netzwerk läßt grüßen.

So oder so, wenn wir HTTP-Requests an den Server schicken, landen diese im Allgemeinen nicht direkt beim MVC-Controller, sondern werden über einen FrontController dispatcht. Das gibt es in einer klassischen GUI-Anwendung so überhaupt nicht.

Ein weiterer wesentlicher Unterschied ist, dass wir (nicht zuletzt wegen der Rechnergrenze) im View auf dem Server normalerweise eine vollständige HTML-Seite generieren und eben nicht nur ein GUI-Element innerhalb der HTML-Seite aktualisieren.

Man sieht, dass durch Javascript und AJAX wieder viel mehr Elemente des klassischen MVC im Web auftauchen, allerdings sprechen wir dann von MVC in Javascript und nicht MVC in PHP. PHP wird dabei eigentlich zur wenig intelligenten Middleware, die Daten herumschaufelt, degradiert.

Eine sehr wichtige Frage, die wir auch ausführlich diskutiert haben, ist, wo man nun Geschäftslogik und Datenzugriff platziert. Entgegen der landläufigen Meinung entsprechen Model, View und Controller nicht den drei Schichten der klassischen Software-Architektur Präsentation, Logik und Datenzugriff. Das sind zwei unterschiedliche Architekturmuster oder -paradigmen, die erst einmal nichts miteinander zu tun haben. Der MVC-View ist in der Präsentations-Schicht, aber sowohl Model als auch Controller sind in der Logik-Schicht angesiedelt.

Kein Datenzugriff

Das bedeutet, dass weder im Controller noch im Model Datenzugriff erfolgen soll. Das Konzept einer Datenbank ist innerhalb der Geschäftslogik unbekannt, ebenso HTML. Für die Geschäftslogik soll es (im Sinne einer guten Software-Architektur) egal sein, ob Daten aus einer Datenbank, einer Datei oder einem Webservice stammen. Ebenso soll es egal sein, ob die Ergebnisse später als HTML-Seite oder XML oder JSON präsentiert werden.

Genau das ist es, was MVC im Web eigentlich ausmacht: die Trennung unterschiedlicher Belange. Leider wird genau dieser Aspekt von gängigen Frameworks nicht erzwungen. Niemand hindert dort den Entwickler daran, etwa innerhalb einer Model-Klasse auf superglobale Variablen zuzugreifen. Ebenso wird man nicht bestraft, wenn man innerhalb eines Controllers SQL-Befehle notiert.

Die Reaktionen der Teilnehmer auf die Session waren sehr gut. Ich hatte im Anschluß noch einige interessante Diskussionen, bei denen der Wunsch geäußert wurde, auf einer der nächsten Konferenzen mehr daruber, wie man Geschäftslogik organisiert und wie man sie unabhängig von der/den Datenquelle(n) hält, zu erfahren.

Ein Framework-Entwickler sagte mir, er würde sein Framework zukünftig nicht mehr als MVC-Framework vermarkten, weil das eigentlich kein MVC sei, was sie da machen. Ich denke mal, das kann man als Erfolg werten. Über MVC kann man viel, oft und lange nachdenken und diskutieren, auch ich selbst entdecke immer wieder neue Aspekte. Ich würde mich freuen, wenn wir die Diskussion auf einer der nächsten einschlägigen Veranstaltungen fortsetzen könnten.

Tags: PHP, Unconference, MVC, AJAX, XML, HTTP, Hamburg, Framework

««« Vorheriger Eintrag

Nächster Eintrag »»»

Kommentare?

Kommentare bitte per E-Mail.