Es lohnt sich die Folien dieser Vorträge (Vortrag 1, Vortrag 2) sehr genau zu studieren. Denn auch wenn Cairngorm als Architektur-Framework schon einige Jahre eingesetzt wird und viele Flex Entwickler mit Cairngorm gut vertraut sind, herrschen noch sehr unterschiedliche Meinungen und Strategien beim Einsatz des Frameworks, nicht zuletzt wegen der mangelhaften Dokumentation.

Auch wenn sich Cairngorm in der Grundstruktur über die Jahre kaum weiterentwickelt hat, haben sich die aktuellen “Best Practices” bei Adobe Consultings wesentlich geändert. Ein Grund mehr, auch seinen eigenen Einsatz von Cairngorm zu überdenken.

Hier ein Überblick über die Experten-Tips:

1. ModelLocator
• ModelLocator ist im wahrsten Sinne des Wortes ein “Ort für Models” D.h. der Model Locator hält typisierte Model Objekte. Dazu gehören u.a. Presentation Models, globale Informationen (z.B. UserVO), globaler Applikation-State. Dazu gehören aber keine Eigenschaften wie z.B. “address”, “country” usw.
• Schluss mit den unzähligen “ModelLocator. getInstance()”! Der ModelLocator wird nur einmal im (Haupt-)View über getInstance() aufgerufen. Alle weiteren Views werden ihre notwendigen Models injiziert (Stichwort: Dependencies Injection ). D.h. ein View wird nur mit seinen notwendigen Daten per Referenz “befüllt”, z.b. mit seinem Presentation Model (siehe Punkt 2) oder einem Top-Model-Object. Aber auch mit dem ModelLocator selbst, falls es notwendig ist.
2. Presentation Model (PM)
• Vorab: Wer mehr über den Einsatz von Presentation Models erfahren möchte, hier zwei sehr empfehlenswerte Artikel:
  - Martin Fowler: Presentation Model
  - Paul Williams: Presentation Patterns – Presentation Model
• PM präsentiert das Verhalten und die State eines oder mehrerer Views, d.h. soviel Code wie möglich wird von dem View in sein PM ausgelagert. Dazu zählen: View-Daten (z.B. gefilterte Listen von Produkten), View-States (z.B. selectIndex eines ViewStackes), View-Logik (z.B. State eines Absende-Buttons innerhalb eines Formulars)
• Ein View beobachtet über Bindings Änderungen von Model-Daten.
• Ein View kennt sein PM, aber ein PM nicht die Views.
• Über das PM wird die View und Business-Logik getrennt. Sollte ein PM zu viele Verantwortlichkeiten erhalten, empfiehlt es sich, Teile der Business-Logik in weitere externe Klassen auszulagern
• PM verarbeitet auch Fehler, z.B. bei serverseitgen Abfragen von Daten (siehe auch Punkt 3)
3. Updaten von Model-Daten
• User-Gesten vom View werden direkt an sein PM weitergegeben, um von dort Cairngorm-Events abzufeuern. Das Event landet wie gehabt im entsprechenden Command.
• Commands sollten keine direkte Referenze zu Models haben und somit die Model-Daten selbst nicht updaten. Stattdessen schicken die Cairngorm-Events Model-Callback-Funktionen als Referenzen mit, welche dort (z.B. im PM) direkt geupdated werden
• Serverseitige Daten werden über Delegates abgearbeitet, welche über Responder das Ergebnis weitergeben. Dabei wird empfohlen, für die Responder eigene Klassen anzulegen. D.h. die Commands brauchen nicht das IResponder-Interface zu implementieren.
• Im Command werden Responder-Klassen erstellt, welche ebenfalls ebenfalls eine Referenz zu den Callback-Funktionen erhalten, welche von den Cairngorm-Events “übermittelt” werden. Damit können die Responder innerhalb ihrer result- oder fault-Methode diese Callbacks aufrufen, welche dann Model-Daten updaten. Um das Fault-Handling zu vereinfachen, wird zudem eine Super-Klasse für die Responder emfpohlen, welche das Error-Handling bereits implementiert
4. Controller
• Große Controller sind zu vermeiden: Statt den Controller unübersichtlich mit unzähligen “addCommand(…, …)” zu befüllen, bieten sich SubController an oder einfach auch Methoden für bestimmte Mappings, wie z.B. addAccountManagementCommands()
5. Views
• View erhalten ihre Daten über Binding zu ihrem Model (PM)
• Logik der Views wird weitgehendst in PM ausgelagert (siehe Punkt 2). Dazu zählt aber nicht die Logik des User-Interfaces, wie z.B. Animationen, Drag und Drop, Stylen von Grafische Elemente, usw.
• Custom Components sollten keine Referenz zum ModelLocator haben. Stattdessen sollten die notwendigen Daten injiziert werden (siehe auch Punkt 1)
6. Unit Testing
• Aufgrund des massiven Einsatzes von PM sind Model-Daten gut testbar! Falls nicht, sind in den PM noch zu starke Abhängigkeiten.
• Business-Logik in eigenen Klassen halten. D.h. raus aus Commands, Delegates, Responders.
• Zum Testen von Delegates empfiehlt sich das Verwenden von Factory-Klassen, welche mit Einsatz von Interfaces ein “produktives” und ein “testbares” Delegates liefert
7. Cairngorm Plugin für Flex Builder
• Absolut empfehlenswert für noch schnelleres Arbeiten: Cairngorm Plugin bei Adobe Open Source

Übrigens: In den o.g. Folien der Präsentationen der Adobe Consultings findet Ihr auch eine Menge Code-Beispiele, die es sich ebenfalls lohnen, genauer unter die Lupe zu nehmen

[NACHTRAG v. 13.01.2009] Ab heute ist die o.g. Cairngorm Präsentation von der Adobe MAX in San Francisco als Video auf AdobeTV online (via: Ted Patrick ). Hier könnt Ihr sie selbst noch einmal verfolgen. Prädikat: Sehr lohnenswert!! [/NACHTRAG]

-Jens
www.websector.de

Hier findet Ihr alle Videos aufgeteilt in 5 Sessions:

• Teil 1
• Teil 2
• Teil 3
• Teil 4
• Teil 5

-Jens

Für Fragen zu den Tutorials gibt es außerdem ein eigenes Flex-In-A-Week-Forum.

Und nicht zu vergessen, bei allen weiteren Fragen zu Flex gibt es ja noch die flexughh-Meetings, wo Ihr Euch regelmäßig mit weiteren Flex-Begeisterten aus Hamburg und Umgebung austauschen könnt. Übrigens, das nächste Meeting ist am 25. August

-Jens

1. 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

2. 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.

3. 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.

4. 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.

5. 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 ->Mediator

   Auch 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.

6. 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.

7. 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”.

8. 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.

9. 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.

10. 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

Adobe Flex
Vorteile:

• Die Darstellungschicht wird komplett auf den Client geladen.
• Es werden nur noch Businessdaten über das Netzwerk transportiert.
• Geringere Netzwerklast.
• Ausgereifte Backendtechnologie (Adobe LiveCycle Data Service).
• Ausgereifte Entwicklungsumgebung Flexbuilder.
• Flex steht nun unter der Mozilla Public License.
• Weite Verbreitung des Flash Plugins für Standardbrowser.

Nachteile:

• Der erstmalige Upload auf den Client (Browser) kann etwas Zeit in Anspruch nehmen.
• Das Flash Plugin (Version 9) für den jeweiligen Browser ist nötig.
• Der Flexbuilder ist kostenpflichtig.
• Der LiveCycle Data Service ist für mehr als ein CPU (Cluster) kostenpflichtig.