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

Flex, par nature, est "déjà MVC". Le dataProvider d'une ComboBox, par exemple, est séparé du composant ComboBox, pour ne citer que cet exemple. Je vais donc utiliser des techniques basiques de Flex:

• Data Binding
• Communication par évènement
• Typage fort, héritage,  et utilisation des interface
• Définition MXML d'objets

Le plus important ici est peut-être l'aspect "composant" qui va être adopté. Celui-ci permet la réutilisation du code de manière simple.

Mis en application mais pas testé pour 100% des cas d'utilisation

L'architecture que je vais présenter à été mise en place pour une application Flex que je développe pour l'entreprise dans laquelle je travaille, Business Geografic. Le concept est tellement générique qu'il peut à mon avis, être appliqué à la plupart des applications. Quelques points n'ont pour l'instant pas été testés comme la gestion de l'internationalisation (i12n) des composants (langues différentes). Même si cela ne devrait pas poser de problème, je n'ai pas encore tenté une mise en place.

Si vous souhaitez migrer une application déjà développée autour d'un framework ou de votre technique à vous, il vous faudra aussi passer du temps pour découper vos classes si cela n'est pas déjà fait. Le mieux est bien sûr de partir "from scratch" mais ce n'est pas forcement votre cas.

Architecture applicative au niveau projet

Avant de taper dans le gros du code, voici la répartition (un peu simplifiée) des projets. Vous pouvez faire avec plus ou moins de projets/librairies suivant le métier mais cela dépend de votre métier. Dans les prochains exemples, j'utiliserai FT comme préfixe pour les packages et les noms de projets (comme Flex-Tutorial ). Bien sûr vous devrez remplacer les préfixes, namespaces & Co par les noms/initiales de votre entreprise.

Librairies

L'utilisation des librairies Flex est ici primordiale pour la réutilisation de votre code. Imaginez par exemple que vous vouliez faire une implémentation Air et une implémentation Adobe Flex (web) de la même application. Si toutes vos sources sont dans le même projet (Flex Application), vous devriez dupliquer votre code.

Certaines librairies peuvent être re-decoupées en plusieurs librairies selon vos problématiques métier.

• AssetsLibrary: Cette librairie va contenir tous les icônes et ressources (audio, pictos, …) que vous allez embarquer dans votre application (Embed). Elle va contenir les fichiers ressources mais aussi des classes d'accès vers ces ressources. Le but de cette Flex Library est de centraliser tous vos assets mais surtout de les compiler dans un SWC qui va être réutilisé par toutes les applications. Cela va surtout vous permettre de sauver énormément de temps de compilation au niveau projet. En effet, le transcodage des icônes est une opération très longue que vous ne voulez pas faire à chaque compilation. En compilant vos éléments Embedded dans un SWC, la compilation se fait une fois et à chaque fois que vous ajouter des icônes, ce qui ne devrait pas arriver très souvent par rapport au nombre de compilations.
• FlexComponents: Cette librairie va contenir tous les composants Flex que vous avez crée ou téléchargé sur le net qui sont génériques. Dans cette librairie, aucun composant "métier", simplement des petits composants utiles (TextInput avec Prompt, ComboBox améliorée, ColorPicker avancé, …). Ces composants doivent pouvoir être utilisés sans aucune dépendance métier.
• FlexUtils: Librairie contenant simplement des classes utilitaires que vous codé ou téléchargé. Là aussi, aucune composante métier. Par exemple, on pourra y retrouver des ColorUtils, des StringUtils, des implémentation de HashMap, … C'est aussi ici que vous pourrez intégrer un Logger si vous en utilisez un.
• FTFramework: Voilà le projet le plus important puisque c'est lui qui va contenir les bases de votre code métier. C'est ici que vont se trouver tous les "Managers" comme je les appellerai par la suite et leur implémentation de base. C'est aussi ici que vont se trouver tous vos composants métier (contrairement aux composants génériques qui vont se trouver dans la librairie FlexComponents).

Applications

Les projets de type Flex Application (ou Air Application) vont être liés à l'ensemble de ces librairies. C'est dans l'application que l'on va mettre en place les liaisons entre les différents "Managers" présents dans le FTFramework grâce à du DataBinding. C'est aussi dans les projets que l'on va créer les implémentations métier spécifiques par dessus les Managers de base. Ce sera plus clair avec des exemples de code plus tard .