Jesse Warden’s großartiger Artikel „10 Tips Working With Cairngorm“ gab mir die Idee, ebenfalls 10 Tips für PureMVC zu veröffentlichen. Ich arbeite seit über einem halben Jahr sehr intensiv mit PureMVC und – das ist kein Geheimnis – mir gefällt das Framework außerordentlich.
-
Denke in (Pure)MVC
Wie starte ich mit PureMVC? Kurze Antwort: Denke in (Pure)MVC! Denn wie der Name schon sagt, PureMVC basiert auf das klassische Model-View-Conroller Meta-Design-Pattern. Zwar werden die Core-Akteure nicht direkt instanziiert, sondern über das Facade-Pattern gehandelt, aber jedes Mitglied von PureMVC hat seine eigene und klar definiert Rolle innerhalb der drei Bereiche Model, View und Controller:
– Proxies = Model
– Mediatoren und ihre View Components = View
– Commands = Controller -
Erstelle API’s für die View Components
Eine View Component kann eine Standard UI Komponente (z.B. DataGrid) oder auch eine eigene Komponente (wie z.B. eine Welt in einem Spiel) oder irgendetwas anderes sein. Um ihren Status oder Verhalten zu ändern, rufe von einem Mediator nicht ihre „public“ Methoden auf, sondern erstelle dafür eine eigene API.
Denn einer der Vorteile von PureMVC ist es, neutral gegenüber den verwendeten Technologien zu sein. Ein Beispiel: Vor kurzem habe ich habe eine „reine“ Flash-Applikation gebaut, welche nicht das Flex Framework nutzt. Nun soll diese Applikation als AIR Anwendung zum Einsatz kommen, um auch die geniale File system API von AIR zu nutzen. Dafür müssen zwar die vorhandenen View Components das Flex Framework nutzen und dementsprechend erweitert bzw. „getauscht“ werden, allerdings nicht ihre Mediatoren oder irgendwelche anderen Akteure von PureMVC.
-
Nutze einen Mediator für mehrere View Components
Um mehrere View Components zu steuern, reicht oft ein Mediator aus. Mit anderen Worten: Nicht alle View Components brauchen einen eigenen Mediator.
Zum Beispiel: Stelle Dir eine ApplicationControllBar vor, welche einen TextInput, einen Button und möglicherweise noch weitere Komponenten beinhaltet. Erstelle für alle diese Komponenten nur einen Mediator, genant „ApplicationControlBarMediator“, und referenziere und caste darin alle notwendigen Komponenten so, wie Du es mit der „Haupt“-View Component machen würdest.
-
Lass‘ Events bubbeln
Was aber, wenn Du nicht mehrere View Components innerhalb eines Mediators referenzieren und dennoch auf User-Interaktionen reagieren möchtest? Dann erstelle eigene Events und lasse sie bis zur „Haupt“-View Component bubbeln, welche dann der Mediator abfängt.
Zum Beispiel: Klickt der User einen Button, welcher sich innheralb der „Haupt“-View Component befindet, wird ein eigener Event abgefeuert. Auf diesen hört der Mediator, ohne jedoch irgendein Child innerhalb der „Haupt“-View Component kennen zu müssen.
-
Kommuniziere über Notifications so oft wie möglich
Notification sind die „Events“ von PureMVC. Zur Kommunikation zwischen den drei Bereichen Model, View und Controller benutze Notification so oft wie möglich. Dazu gehören folgende Szenarien:
(Kommunikation von -> zu)
– Mediator -> Proxy (über gemappte Commands)
– Proxy -> Mediator
– Proxy -> Command
– Command ->MediatorAuch wenn die Möglichkeit besteht, einen Proxy direkt von einem Mediator anzusprechen, ändere keinen Proxy von einem Mediator aus. Es ist eine schlechte Praktik den Status eines Proxy (Model) von einem Mediator (View) aus zu ändern, ohne einen Command (Controller) zu verwenden.
-
Benutze Commands / MacroCommands so oft wie möglich
Commands erledigen innerhalb von PureMVC den Job auf der Controller-Seite. Dazu zählen: Aufrufen und Interaktion mit Proxies, Kommunikation mit Mediators oder das Ausführen weiterer Commands.
Auch wenn ein Command nur einmal benutzt wird oder auch nur zwei Zeilen Code beinhaltet, nutze ihn so oft wie möglich. Denn um diesen Command irgendwann oder irgendwo noch einmal in Deiner Applikation aufzurufen, reicht das Versenden einer einzigen Notification. Auch ist es in Zukunft leicht, den Command mit weiteren Aufgaben zu versehen. Und so – das ist besonders wichtig – weißt Du immer, wer den State der Proxies (Model) ändert.
Frage: Musstest Du schon einmal mehrere Commands in einer bestimmten Reihenfolge ausführen? Dann nutze in PureMVC die MacroCommands, welche SubCommands („normale“ Commands) sequenziell ausführen.
-
Nutze RemoteProxies zum Versenden und Empfangen von Daten
Um Daten zwischen Client- und Server-Seite auszutauschen, nutze RemoteProxies. Diese basieren auf den „normalen“ Proxies von PureMVC und organisieren die Serveraufrufe wie z.B. HTTPServices, RemoteObjects usw.
Ein Beispiel: Um ein serverseitiges RemoteObject für den Login eines Users aufzurufen, erstelle ein (Remote-) Proxy genannt „LoginProxy“. Dieser „LoginProxy“ führt den gesamten Job für das Versenden und Empfangen der Daten aus. Falls einmal die serverseitige Implementation für den Loginprozess geändert werden sollte, brauchst Du nur einen Ort Deiner Applikation anpassen – den „LoginProxy“.
-
Entferne nicht benutzte Mediators
In bestimmten Fällen werden Mediators und ihre View Components nicht mehr verwendet. Entferne dann den Mediator über facade.removeMediator(MyMediator.NAME); und verbinde diesen Vorgang mit einer selbst erstellten destroy(); Methode, um gleichzeitig die an den Mediator gekoppelten View Components mit all‘ ihren Listeners, Timer, Referenzen usw. für eine erfolgreiche Garbage Collection zu entfernen.
-
Die Kraft der VO’s (Value Objects)
Es ist richtig, dass bei PureMVC der Ort zum Halten der Model Daten die Proxies sind. Und es ist ebenfalls richtig, dass die View Components nichts über die Facade und den Rest der PureMVC Applikation wissen brauchen. Das bedeutet allerdings, das keine View Component einen direkten Zugang zum Model hat.
Um dieses Problem zu lösen, halte die Daten in VO’s und erstelle in den View Components eine Referenz zu diesen her. Mit Hilfe des genialen Data Binding Features in Flex können die View Components sehr leicht auf Änderungen im Model reagieren. Auch werden damit keine Regeln gebrochen, da die VO’s keine Hauptakteure von PureMVC sind und so bedenkenlos in View Components eingesetzt werden können.
-
Studium-Unterlagen erhältlich
Cliff Hall hat einen absolut genialen Job gemacht: Du findest nicht nur exzellente Dokumentationen wie „Framework Overview„, „Best Practices“ oder „Conceptual Diagram„, sondern auch super hilfreiche Studium-Unterlagen zu PureMVC. Teste sie aus!
P.S.: Dieser Beitrag ist eine Übersetzung des englischen Artikels „10 tips for working with PureMVC“ zu finden auf meinem WS-Blog. Fachbegriffe sind bewusst nicht mit übersetzt 😉
-Jens
Hi,
vielen Dank für deine Übersetzung der 10 Gebote. Es ist eine Wohltat ab und zu deutsche Texte zu lesen!
Mich würde interessieren, welche Unterlagen du unter 10. gemeint hast, da der Link tot ist.
Vielen Dank Jörg
Hallo Jörg,
„Gebote“ klingt gut, sollten eigentlich nur Tips sein 😉
Unter Punkt 10 waren Studienunterlagen gemeint, so eine Art Step-by-Step Tutorials. Der Link ist wahrhaftig tot, ansonsten einfach mal bei Bedarf ins PureMVC-Forum posten: http://forums.puremvc.org/
-Jens
[…] schreibt häufig über seine Erfahrungen mit dem Framework. Er hat zudem den lesenswerten Beitrag „10 Tipps für das Arbeiten mit PureMVC“ verfasst. Nach dem Verweis auf so viel Lektüre, soll’s nun aber auch für den Einstieg an Code […]
Punkt 2 ist mir nicht ganz klar: Ich habe beispielsweise in meinem Mediator eine Instanz eines Filmplayers (eigene Klasse) liegen. Sollte ich dann nicht die public function play() der Instanz aufrufen? Was ist damit genau gemeint, dafür eine API zu schreiben? Vielen Dank für die Tipps!
Weitere Fragen:
a) Sollte man einmalige Commands auch entfernen (removeCommand)?
b) Kann ein Command sich selbst entfernen? Sollte er das?
c) Ich habe sehr viele Commands. Wie organisiere ich sie am Besten? Gibt es irgendwo ein Beispiel (Screenshot) von der Nutzung von vielen Commands (um deren Bezeichnungen zu sehen)? Das wäre toll!
[…] German Version 10-tips-fur-das-arbeiten-mit-puremvc […]
Ich schließe mich Jerry an. Was soll das heissen, eine API zu erstellen anstatt die public methods aufzurufen? Wo ist der Unterschied?