Adobe Cairngorm vs. GraniteDS Tide MVC

Wer eine etwas umfangreiche Flex Applikation entwickelt wird früher oder später nicht um ein vernünftiges MVC Framework herumkommen. Man kann sich noch soviel Mühe geben und mittels Code-Behind Pattern Layout von Logik trennen, aber der Einsatz eines MVC Frameworks bringt deutliche Vorteile die man nach kurzer Zeit nicht mehr missen möchte.

Nun gut. Am Anfang der Entwicklung nutzte ich das Adobe Cairngorm MVC Framework welches sehr stark an die alt hergebrachten J2EE Patterns angelehnt ist. Zur Anbindung an das Spring Backend verglich ich BlazeDS mit GraniteDS und habe mich für Letzteres entschieden, was ich bis heute nicht bereut habe.

Tide ist Teil von GraniteDS und als MVC Framework zu gebrauchen. Zusätzlich bringt es noch sehr viel andere nützliche Features (ServerPush/Security etc.) mit. All dies kommt sozusagen mit GraniteDS als nette Beigabe mit.

Kürzlich habe ich entschieden Cairngorm durch Tide zu ersetzen (ein Framework weniger). Die ersten Schritte wurden bereits umgesetzt und es haben sich viele Vorteile als auch einige unschöne Dinge (mit denen man leben kann) gezeigt.

Cairngorm:
Das Prinzip bei Cairngorm ist wie folgt: Teile dem Controller mit, welcher Command bei welchem Event auszuführen ist. Im Command nutze das Business Delegate Pattern und handle den Result in der Command Klasse. Der Delegater nutzt wiederum das ServiceLocator Pattern um das Backend aufzurufen.

Nachteil: Folgt man dieser Vorgehensweise, spürt man recht schnell wie man das DRY Prinzip verletzt. Immer wieder Event and Command binden, usw. Die Anzahl der Command Klassen wächst somit pro Eventtyp. Irgendwie schlecht. Viel zu viel Code für einen einzigen Button Click.

Vorteil: Die IDE als auch der Compiler decken Fehler in der Implementierung auf, da alles typisiert ist.

Tide:
Hier wird Loose Coupling gross geschrieben. Meiner Ansicht nach etwas zu GROSS.
Vorteil: Sehr viel weniger und redundanter Code, schickes MVC Framework, integriert sich gut und nicht zu aufdringlich, d.h. der Code bleibt relativ sauber, wenige Tide Dependencies.

Nachteil:
Observermethoden werden über AS Annotationen markiert. Der EventType ist dabei ein String:
[Observer("ADD_USER")]
public function addUser():void

Das Event wird gemäss Standard geworfen:
dispatchEvent(new UserEvent(UserEvent.ADD_USER));
-> Fehler werden zur Laufzeit sichtbar und sind nicht trivial zu finden. In der IDE ist es nicht möglich Referenzen ausfindig zu machen (nur mit einem file search).

Ähnlich wie bei Spring wird ein Tide Context aufgebaut der die markierten(!) Klassen verwaltet. Eventhandling und Auffindung der Services läuft über diesen Context. Einen Service findet man über eine dynamische Klasse:
tideContext.userService.findAll(onUsersLoaded);
Vertippt man sich stattdessen und schreibt:
tideContext.userervice.findAll(onUsersLoaded);
meckert der Compiler nicht und auch zur Laufzeit tritt kein Fehler auf (dynamische Proxy Klasse)!
Das Java Pendant sieht folgendermaßen aus:
class UserService, Methode: List findAll().

Der Parameter onUsersLoaded ist eine Eventhandler Methode.

Thema Security: Grosse Probleme ergaben sich bei der Nutzung der Spring Security (die von GraniteDS eingerichtet ist) und dem Cairngorm Framework. Cairngorm wrapped auftretende Exceptions und es ist nicht ohne weiteres möglich an die SecurityExceptions von GraniteDS ranzukommen. Mühseelig die Fehlercodes und Texte auszuwerten um an den Cause zu gelangen. Diese Probleme hat man nicht wenn man Tide benutzt!

Alles in allem muss ich aber sagen, dass ich Tide dem Cairngorm bevorzuge zumal ich sowieso GraniteDS benutze. Wer BlazeDS nutzt sollte sich möglicherweise noch andere MVC Frameworks ansehen bevor er sich für Cairngorm oder Tide entscheidet.