Apache Adobe Flex TutorialTutoriaux Adobe Flex & AIR en Français

Flex 4 – (2) Conception d'une architecture Flex orientée composant

Si vous suivez flex-tutorial, vous avez sûrement vu que je parlais que peu souvent des framworks MVC (Cairngorm, PureMVC, Mate, Parsley pour ne citer que les plus populaires). Cela vient du fait qu'après avoir regardé la plupart des frameworks, aucun ne me paraissait correct.

Les problèmes apportés par les frameworks MVC

Plusieurs raisons (subjectives) à cela:

• Aucun framework n'est "ultra-populaire" et écrase tous les autres. C'était le cas pour Cairngorm au départ car Adobe poussait à utiliser son produit mais le choix est maintenant plus hétérogène. Admettons que l'on apprenne le fonctionnement de Cairngorm et qu'on le maîtrise. Si vous tombez sur un poste où tous les projets utilisent PureMVC, vous pouvez mettre vos compétences au placard.
• La majorité des frameworks MVC pour Flex amènent avec eux, une architecture (dossiers/sources). Si vous décidez que pour une raison X, le framework ne convient plus à votre besoin, vous aurez un gros travail de refactoring à faire qui va se révéler laborieux (encore plus avec les bugs de Flex Builder 3, corrigés pour Flash Builder 4). Quand vous vous engagez sur un framework, vous êtes "couplé" à lui.
• Les frameworks basés sur les annotations (Mate, Parsley, …) ne vous imposent que très peu d'architecture et viennent se greffer sur votre code. Le problème est que de cette manière, beaucoup de choses se passent "under the hood" de manière un peu magique, et cela peut rendre le debugging laborieux.
• A la base, le paradigme MVC a été crée pour avoir des classes qui ne sont pas couplées entre elles et les plus atomiques possible (une des bases de la programmation OO). Pour certains frameworks MVC comme Cairngorm, vous devez sans cesse faire des héritages sur des classes du framework (tous les Event par exemple dérivent de CairngormEvent). D'autres comme Robotlegs vous obligent à enregistrer vos objets (à les "mapper") dans des Singletons. Cairngorm utilise lui aussi des Singletons pour un peu tout (Services, Model, …) ce qui va nuire à la ré-utilisabilité et à la modularité de votre code.
• Aucun des composants Flex disponibles sur le net n'est basé sur les classes d'un framework en particulier. Pour rester neutre, l'écrasante majorité des composants que l'on trouve sur le net ne sont pas écrits en se basant sur un framework. On peut donc se retrouver avec un code hétérogène.
• L'utilisation d'un framework implique que tous les développeurs comprennent les concepts d'utilisation du framework. Cela va venir s'ajouter au temps de développement du projet.
• En plus de "subir" la roadmap d'Adobe sur le SDK Flex, vous devrez parfois attendre la migration de telle ou telle fonctionnalité sur le framework choisi. Comme tous ne sont pas open source, vous pouvez vous retrouver bloqué.

Ces considérations sont générales à tous les framework. Chaque framework ayant ses spécificités, va aussi apporter d'autres points bloquants (trop long de tous les faire). Après il y a sûrement des points positifs à l'utilisation de chacun de ses frameworks mais qui, selon moi, ne pèse pas assez lourd dans la balance. Bien sûr, si vous voulez lancer un petit débat, vous pouvez laisser un commentaire à cet article .

Adopter une approche différente

Pour le projet sur lequel je travaille actuellement, il me fallait donc trouver une solution cohérente, extensible et ré-utilisable pour l'architecture du projet. Ayant écarté l'utilisation d'un framework en particulier, il fallait donc trouver une solution qui ne m'oblige pas à re-inventer la roue. L'approche que j'ai adopté a été inspirée au départ de cet article:

Flex Best Practices – Models, Views, and Controllers

Le challenge avec l'utilisation du paradigme MVC (Model-View-Controller) est que chacun a un peu son implémentation (plus ou moins passive).

J'ai donc décidé de simplement intégrer les concepts-clé de la POO:

• Couplage faible entre les objets
• Pas de singletons (variables globales)
• Séparation of concerns (cloisonnement des fonctionnalités de chaque objet pour qu'il soit le plus atomique possible)
• Keep It Simple and Stupid & Don't Repeat Yourself