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.

DB adé, welcome to the Cloud!

Ein Gedanke der mich schon seit Wochen plagt und den ich nun mal aus meinem Kopf haben möchte, daher hier ein Post dazu.

Mit dem neusten Schrei Cloud Computing, Amazon EC2 usw. habe ich mich noch nicht sonderlich befasst, allerdings kam mir direkt eine Idee sowas ähnliches gebrauchen zu können....

Was wäre wenn...ich meine Applikation nicht komplett virtualisieren möchte, da sie ja keine reine Internet Applikation ist, sondern vielmehr eine Intranet Applikation, oder auch aus dem Grunde, dass ich nicht wirklich diesen großen Schritt auf einmal gehen möchte :-)

Zum Problem: Wie oft macht man sich schon beim Entwurf des Domain Modells Gedanken um Performanz. Ist dies in dieser Phase wirklich so berechtigt? Oder sollte man das Geschäftsmodell nicht einfach nach den wirklichen Business Requirements entwerfen und die Performance Leaks im Zuge der Iterationen aufdecken?!

Egal wie, aber im Endeffekt zielt vieles darauf ab, den DB Zugriff zu optimieren, d.h. auch das Domain Model zu verändern (was nicht immer im Sinne des Erfinders ist).

Also wie wäre es, wenn ich mir um die Persistenz (in Form einer DB) keine Gedanken machen müsste?

Wie wäre es wenn ein Freak mit viel Zeit daher käme und mir einen JPA Provider für eine Cloud anbieten würde?

Machen wir uns nicht zuviel Gedanken um Ausfallsicherheit und vollkommenes Data Recovery?

Also nehmen wir mal an, es gäbe da was, was mir eine saubere transaktionale Implementierung der JPA bietet, somit könnte ich diese ohne irgendwelche groben strukturellen Änderungen in meiner Applikation benutzen.

Engpässe wären lediglich im Netzwerk I/O zu sehen - da die Cloud ein SuperB Computer darstellt, der für mich als Anwender kein Nadelöhr in Sachen File I/O ist.

Was ich doch bis dato immer noch nicht verstehen kann, dass ich als Designer des Domain Models Rücksicht nehmen muss, auf irgendwelche alt hergebrachten Misstände der Datenbanken.

Vielleicht muss ich mich auch mit dem Thema Cloud Computing noch etwas mehr auseinander setzen. Als nächstes werde ich mir mal ansehen was das CloudTools Projekt (google hosted) zu diesem Thema beitragen kann und wie sich der Spring dm Server in dieses Environment integriert. So, stay tuned...