Die Adobe Consultants Eric Garza, Peter Matin und Alistair McLeod hielten auf der MAX in San Francisco und Mailand hervorragende Vorträge zu Cairngorm. Ihre Themen lauteten „FIA Development with Cairngorm – Tips from the Experts“ und „Flex Development with Cairngorm„.

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

Ü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