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.

Noch eines Vorweg: So ganz kann ich mich mit dem Mate-Framework nicht anfreunden und auch diese “Best Practice” halte ich nicht für den Königsweg. Wer aktuell auf der Suche nach einem guten Flex-Framework ist und die freie Wahl hat, dem empfehle ich PureMVC. PureMVC gibt (nach meiner Ansicht) einen sauberen und schlanken Software-Entwurf vor. Gerade in größeren Projektteams mit wechselnden Leuten kann es vorkommen, dass beim Mate-Framework jeder Entwickler seinen eigenen Software-Entwurf mitbringt (wie gesagt: Mate unterstützt eine lose Kopplung zwischen Objekten, gibt jedoch keine einheitliche Struktur vor). PureMVC (mit einer sehr guten Dokumenation) hingegen garantiert bei richtiger Anwendung eine konsistente Umsetzung und reduziert (zwar mitunter intessante - aber zeitaufwendige) Entwurfsdiskussionen. Auch empfinde ich das Handling mit der Mate-Event-Map als unübersichtlich, was jedoch eine reine Geschmackssache sein kann. Veranschaulicht würde ich sagen: PureMVC verhält wie ein gut gewartetes Mietauto mit Navigationssystem - man steigt ein, fährt los und kommt mehr oder weniger entspannt am Ziel an. Mate ist eher der expirimentelle Weg, vielleicht wie eine weite Reise auf einem Mofa mit unvollständigen Landkarten - sicherlich sehr interessant - hin und wieder muss man mal basteln - hier und da einige Teile mit Gaffa befestigen - und immer wieder kommt der eigene Orientierungssinn zum Einsatz, der einen auch zeitweise täuschen kann.

Wie bereits erwähnt, gibt es viele Möglichkeiten mit dem Mate-Framework ans Ziel zu kommen. Eine ist die Orientierung am Model-View-ViewModel-Pattern, eine Mutation der MVC-Architektur. Der View-Teil enthält dabei eine Sammlung logikloser UI-Komponenten, die genau eine Referenz auf ein dazugehöriges ViewModel besitzen. Dieses Model sollte beim Erzeugen einer UI-Komponente über die Mate-Map in die Komponente injiziert werden. Das ViewModel enthält die Daten, die in der entsprechenden UI-Komponente dargestellt werden sollen, sowie dessen Zustände. Über Flex-Datenbindung wird die View nach einer Veränderung dieser Daten aktualisiert. Bei einer Benutzeraktion wird eine Funktion im ViewModel aufgerufen, in der die Handhabung dieser Aktion implementiert ist. Das ViewModel kann direkt reagieren und den Zustand der dazugehörigen UI-Komponente ändern (ausschließlich über Datenbindung, ohne dirkete Referenz auf die UI-Komponente). Sollte die Benutzerinteraktion weitreichendere Auswirkungen auf das gesamte System haben, kann das ViewModel ein Event senden und das System auf diese Weise informieren. In Mate werden Events in der Event-Map gefangen und auf unterschiedliche Funktionen in unterschiedlichen Objekten gemappt. Auf diese Weise kann die Event-Map Funktionen in anderen ViewModels aufrufen, die ihrerseits ein Update der dazugehörigen UI-Komponenten erwirken. Weiterhin können auch Funktionen in den Manager-Ojekten (die zum Model-Teil gehören) aufgerufen werden, die global genutzte Datenobjekte manipulieren und einen neuen Zustand der Gesamtanwendung herbeiführen. Über das Mate-Framework können diese globalen Datenobjekte in die ViewModels injiziert werden, um die View dem Anwendungszustand anzupassen. Eine Visualisierung dieses Prinzips steht als PDF zum Download bereit.

Die Besonderheit dieser Architektur stellen die zwei Arten von Model dar. Die eine Art agiert Anwendungsweit und managt global benötigte Daten und Zustände. Die andere Art hält und manipuliert die Daten und Zustände jeweils einer bestimmten UI-Komponente. Der Begriff Model umfasst in diesem Zusammenhang nicht die reinen Datenobjekte (VOs), sondern auch Fachlogik zur Manipulation dieser Daten. Der entfallende Controller aus der MVC-Architektur verteilt sich also auf die Manager(Model)- und ViewModel-Klassen. Das Mate-Framework sorgt für das Zusammenspiel der Bestandteile unter Einsatz von Events und Datenbindung (Prinzip: Data-Injection). Auf diese Weise gibt es keine Abhängigkeiten zwischen den unterschiedlichen Model-Objekten.

Um noch einmal expliziert darauf hinzuweisen: Die UI-Komponenten haben nach diesem Software-Design eine Referenz auf ihre ViewModel! Der Vorteil dabei ist, dass die UI-Komponenten leicht austauschbar sind, etwa gegen Unit-Test-Klassen. Benutzeraktionen können einfach simmuliert werden, indem Test-Routinen die Funktionen im ViewModel aufrufen und anschließend die gebundenen Daten auswerten. Der großen Nachteil ist, dass die UI-Komponenten auf diese Weise nicht universal in beliebigen Projekten genutzt werden können, sondern nur in solchen, in denen auch ViewModels zum Einsatz kommen.  Eine echte Schwachstelle(!) - sind doch gerade UI-Komponenten die Bestandteile einer Anwendung, die sich tatsächlich am ehsten zum Wiederverwenden eignen.

Zum Vergleich noch einmal PureMVC: Hier werden die UI-Komponenten völlig unabhängig vom System mit einer eigenen API entwickelt und in Mediator-Klassen verwaltet. Bei einer Benutzerinteraktion werden Events geworfen, die in Mediators gefangen werden. Die Mediators benachrichtigen das restliche System und reagieren auf Benachrichtigungen, dass sich die View verändern soll. Auf diese Weise können UI-Komponenten entwickelt werden, ohne das die Entwickler etwas über das System wissen müssen in dem ihre Komponenten zum Einsatz kommen. Für mich der bessere Weg zum Ziel.

Über andere Meinungen zum Mate-Framework, Praxiserfahrungen, THE VERY BEST PRACTICE oder Bestätigungen zu meiner Kritik als Kommentar würde ich mich freuen!

Development