Use PureMVC - Drink Mate: Zwei Flex-Frameworks im Vergleich

Zugegeben: Dies wird jetzt kein fairer Vergleich! Von PureMVC bin ich begeistert - vom MATE-Framework halte ich nicht viel, außer “mal ganz Interessant einen anderen Weg zu sehen”. Leider bin ich zur Zeit in einem langfristigen Projekt an MATE gebunden. Einen Weg dieses Framework einzusetzen habe ich bereits in einem anderen Artikel in diesem Blog zusammengefasst und dabei einen ersten Vergleich zwischen MATE und PureMVC gewagt. Nun, knapp 3 Monate später hat sich mein erster Eindruck des MATE-Framework bestätigt: Es ist ein experimenteller Weg und für große Kundenprojekte einfach nicht sinnvoll! Hier eine Zusammenfassung, warum ich PureMVC immer vorziehen würde. [Read more →]

RubyAMF-Checklist

AMF ermöglicht es, einen besonders performanten Datenaustausch zwischen einer clientseitigen Flash- und einer Server-Anwendung zu realisieren. Die AMF-Datenpakete sind sehr klein und garantieren auf diese Weise eine geringe Übertragungszeit. Weiterhin wird das Format vom Flash-Player standardmäßig unterstützt, sodass die Serialisierung und Deserialisierung der Datenobjekte schnell und vor allem automatisch vorgenommen wird. Die Konvertierung in das Nachrichtenformat (und zurück zum Objekt) wird vom Flash-Player übernommen und erfordert keine zusätzliche Implementierungen oder Bibliotheken. Serverseitig nimmt ein AMF-Gateway die Client-Anfragen entgegen, konvertiert den Datenstrom in die entsprechenden Datenobjekte und delegiert diese zur gewünschten serverseitigen Objekt-Funktion (im Fall von Rails zu einer Action eines Controllers). RubyAMF ist ein solcher Gateway. Durch die Installation des entsprechenden Plugin in ein Rails-Projekt kann der Gateway eingerichtet werden. Das so genannte Class-Mapping ermöglicht es, dass die Objekte auf der entsprechenden Gegenseite richtig typisiert ankommen. In dem Fall, dass der Datenaustausch funktioniert jedoch das Class-Mapping fehlschlägt, kommen die Daten-Objekte als anonyme Objekte vom Typ Object in der Flash-Anwendung an. Zur Erleichterung der Fehlersuche, hier eine kleine Checkliste.

1. Die Klassen müssen in der RubyAMF-Config-Datei (config/rubyamf_config.rb) für das Mapping registriert werden.

2. Die Datenobjekte in Rails und Flash müssen die gleichen Attribute besitzen. Die Schreibweise in snake_case oder camelCase kann variieren, jedoch muss RubyAMF dazu entsprechend konfiguriert werden.

3. Bei ActiveRecord-Objekten muss die Datenbank-Migration ausgeführt worden sein.

4. Die ActionScript-Klassen der Datenobjekte müssen als RemoteClass registriert sein. Bei der Metatag-Variante ist darauf zu achten, dass [RemoteClass(alias="ObjectAlias")] direkt vor oder über der Klassen-Deklaration steht.

5. Die ActionScript-Klassen der Datenobjekte müssen in das Flash/Flex-Projekt importiert werden.

6. Die Klassen müssen in den ActionScript-Code importiert werden (!!!).

Mate-Framework best practice - Ein Vorschlag zur Diskussion

Das MATE-Framework soll in Flex-Anwendungen eine lose Kopplung zwischen den einzelnen Programmteilen ermöglichen. Wesentlicher Bestandteil ist eine eine so genannte Event-Map. In der Event-Map werden Flash-Events abgefangen und auf entsprechende Funktionen gemappt. Weiterhin macht sich das Framework das Prinzip der Data-Injection zunutze. Dabei werden Datenobjekte auf Basis der Flex-Datenbindung “von außen” in ein beliebiges Objekt injiziert. Unterschiedliche Objekte können auf diese Weise Daten austauschen, ohne das eine Abhängigkeit zwischen ihnen besteht. Eine weitere Besonderheit von Mate ist, dass die Event-Map ausschließlich Tag-basiert ist und mit MXML implementiert wird. Mehr Informationen zur grundsätzlichen Arbeitsweise, sowie Code-Beispiele findet man auf der MATE-Homepage unter: http://mate.asfusion.com/.

Leider ist die Dokumentation des Framework sehr lückenhaft. Besonders der “Best Practice”-Teil kommt aktuell viel zu kurz (http://mate.asfusion.com/page/documentation/best-practices), ist allerdings dringend notwendig, da Mate sehr wenig Struktur vorgibt. Das Framework unterstützt zwar eine lose Kopplung zwischen den Objekten, garantiert jedoch nicht einen sinnvollen Software-Entwurf! Da ich aktuell in einem Projekt an Mate gebunden bin, habe ich anhand einiger Beispiele auf der Mate-Webseite eine “Best Practice” herausgearbeitet, die ich nachfolgend Dokumentieren werden. Diese “Practice” orientiert sich am MVVM-Designpattern (bekannt aus MS Silverlight) und ist nur eine Möglichkeit, wie das Framework zum Einsatz kommen kann.

[Read more →]

Was soll das Command-Pattern?

Wenn man lernt objektorientiert zu Programmieren, bekommt man eine einfache Faustregel an die Hand: Objekte sollen die Realwelt abbilden. Zur Klassen wird alles was ein Nomen ist. Attribute legen die Eigenschaften dieser Nomen fest, sind also in der Regel die Adjektive. Und Funktionen stellen die Verben da, die eine Handlung beschreiben.

Sobald man jedoch das Verständnis für OOP erworben hat, rückt diese Regel stark in den Hintergrund. Man beschäftigt sich mit “sauberer” Programmierung und einer Trennung der Zuständigkeiten zwischen Darstellung, Daten und Logik (MVC-Architektur), sowie einer losen Kopplung zwischen diesen Programmteilen. Besonders merkwürdig kommt einem das Command-Pattern vor, ein durch die GoF beschriebenes Verhaltensmuster. [Read more →]