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.

1. PureMVC gibt einen schlanken, sauberen Software-Entwurf vor. Dieser beruht auf bewährten Entwurfsmustern der GoF, die 1zu1 umgestzt werden. Viele Entwickler kennen diese Entwurfsmuster und können schnell in das Framework eingearbeitet werden. Zudem hat PureMVC selbst bereits eine weite Verbreitung und kann als Quasi-Standard in der professionellen Flash/Flex-Entwicklung angesehen werden. PureMVC macht Software-Entwicklung effizent! MATE hat dies alles nicht. Es gibt keine Struktur vor und jeder Entwickler bringt seinen eigenen Entwurf mit. Das Software-Design wächst so mit der Anwendung und ewig lange Einarbeitungszeiten für neue Entwickler werden notwendig. Man kann noch so viel dokumentieren, die Struktur wird garantiert nicht einheitlich.

2. PureMVC ist supergut und mehrsprachig dokumentiert - dazu kommen die unzähligen Bücher der GoF über die Grundlagen, auf denen das Framework beruht. Die Dokumentation von MATE ist noch nicht mal in Englisch akzeptabel (wobei sich dies ja ändern kann).

3. PureMVC ist übersichtlich und schlank. Bei MATE verliert man durch die MXML-Event-Map leicht den Überblick welche Instanz wann und wo zur Verfügung steht. Das MATE-Framework vollständig zu verstehen und sinnvoll einzusetzen ist möglich, aber nicht einfach - und das macht es in Kundenprojekten unprofitabel!

4. MATE referenziert Funktionen und Eigenschaften über Strings. Das hat zur Folge, dass Laufzeitfehler fliegen, die eigentlich zur Compilezeit gefunden werden sollten. Auch im Hinblick auf die Performance ist das kein guter Weg.

5. Die MATE-Kommunikation beruht auf bubbelnden Flex-Events. Aus Performance-Sicht ist das teuer. PureMVC benutzt eine vereinfachte Notification-Variante auf Basis des Observer-Pattern. Flex Events werden nur zur Kommunikation von Flex-Komponenten verwendet. Die verwendeten Flex-Komponenten sind dabei absolut lose gekoppelt und vom Framewok unabhängig.

6. Weiterhin beruht die MATE-Kommunikation auf Flex-Databinding. Flex-Databinding ist toll und praktisch, kann aber auch unübersichtlich werden, wenn alles mit allem gebunden ist. Aus Performance-Sicht ist das teuer, vor allem beim Initalisieren! PureMVC informiert das System mit Hilfe von Notifications über Zustandsänderungen.

7. Es geht schnell in MATE Objekte zu verknüpfen: Tag-basiert in MXML. Jedoch die Event-Maps so aufzubauen, dass Objekte zum richtigen Zeitpunkt bereit stehen und auch im richtigen Moment wieder den Speicher räumen, dass kostet Zeit und Nerven!

Mein Tipp: Mate trinken - PureMVC benutzen!

Development