Cairngorm: ViewHelper vs. Presentation Model
Die Benutzung eines Architektur-Frameworks gehört ja heutzutage zum guten Ton. Im eigentlichen Sinne macht ein solches Framework verstärkt Sinn, wenn man in einem Team eine skalierbare Anwendung erstellen möchte und viel Wert auf Sauberkeit und Übersicht legt. Im Prinzip ist so ein Framework aber auch bei kleineren Projekten super nützlich um eine Anwendung für zukünftige Erweiterungen flexibel zu halten.
In meinem letzten Projekt hab ich mich für das von Adobe initiierte Framework - Cairngorm – entschieden. Im Laufe der Entwicklung hab ich mich natürlich mit den Ups und Downs rumärgern müssen die Cairngorm so mit sich bringt. Um sich einige Probleme in Sachen Flexibilität des Frameworks näher zu bringen, muss man sich die Struktur einmal kurz verdeutlichen.
Es läuft in der Regel folgendermaßen ab: Der View dispatched Events, die vom Controller aufgefangen werden und dementsprechende Commands instanziert. Diese Commands sind entkoppelt vom View und verändern nur die Daten in unserem Model. Das Model wiederum updated via Data Binding unsere View-Komponenten. Soweit so gut.
Wenn es darum geht komplexere Probleme zu lösen, die rein vom Gefühl nicht durch einfaches Data Binding gelöst werden können, steht man in Cairngorm vor einigen Entscheidungen zu denen man auch im Netz etliche Diskussionen findet.
Um mal ein Beispiel des Problems zu nennen:
In meiner Applikation will ein User ein Popup aufrufen, welches mit Daten von einem Server gefüttert wurde. Er klickt dafür z.B. auf einen Button, dieser schickt ein Event los, daraufhin wird ein passender Command ausgeführt. Die Frage ist nun, wo implementiere ich die konkrete Methode um das Popup im View zu instanziieren? Ich müsste nach klassischer Cairngorm Best-Practise mein Model aktualisieren, welches wiederum per Data Binding das Popup startet. Gut, dies kann ich einfach mit einem Flag im Model lösen, auf den das View bei Änderung entsprechend reagiert. Im Endeffekt wird aber nicht nur mein Model bei großen Anwendungen durch etliche Flags unnötig aufgeblasen, sondern die Anwendung legt durch viele Listener, Methoden und Referenzen drastisch an Komplexität zu.
In “alten” (2006) Dokumentationen werden für diese Probleme oftmals die sogenannten ViewHelper- und ViewLocator-Klassen referenziert, die für solche Aufgaben zur Verfügung gestellt wurden. Losgelöst vom Command & Model hält ein ViewHelper die View-Komponenten auf dem laufenden.
Aktuelle Cairngorm Dokumentationen schlagen eine Einbindung des sogenannten Presentation Models vor, was dieses speziell im Cairngorm Fall bedeutet kann man unter Anderem hier nachlesen. Für mein bereits fortgeschrittenes Projekt dürfte die Umstellung auf ein Presentation Model aber Aufwand und viel Refactoring darstellen. Etwas was ich aktuell nicht leisten will. Auch bin ich mir unsicher ob die einfacher Umschichtung der Zuständigkeiten alle meine Probleme löst.
Was bedeutet das also für mein konkretes Popup Problem? Auf ViewHelper setzen, was vom Cairngorm Team nicht mehr empfohlen wird? Die klassische Model/Flag/Listener Alternative, was mein Model noch mehr aufbläht? Oder die Methode die wohl am ungünstigen ist: Einfach alles im Command direkt implementieren?
Aufgrund mangelnder klarer Dokumentationen und der daraus resultierenden uneindeutigen und wechselhaften Best-Practise-Methodik, werde ich mir in Zukunft vielleicht noch einmal die Konkurrenz in Form von z.B. PureMVC und Mate anschauen müssen.
Bitte nutzt die Kommentarfunktion und schreib mir eure Erfahrungen.
