Quel Framework choisir pour une application Flex ?

Côté client
Introduction
On trouve plusieurs frameworks architecturaux autour des applications Flex. Ces frameworks ont pour objectif de structurer les applications afin d'augmenter la productivité et la maintenabilité. Ils s'appuient principalement sur le pattern MVC (Model View Controller).
Le pattern MVC a pour but de séparer la présentation de la logique métier.
Généralement, le modèle contient la logique métier, les vues présentent les données et le contrôleur met à jour le modèle en réponse à une action utilisateur.
Dans une application web, une action utilisateur peut entraîner l'appel à un service distant.
Le pattern Command est fréquemment rencontré pour gérer cet appel. Ainsi, lorsque l'utilisateur déclenche un événement, le contrôleur fait appel à la commande correspondante, qui effectue l'appel distant, et met à jour le modèle.
Dans ce contexte, à quoi servent ces frameworks architecturaux ? Tout d'abord à structurer le développement des applications Flex, ensuite à assurer la communication entre les objets modèle manipulés par Flex et les services distants (et les implantations réelles, côté serveur de ces objets métiers).
Les frameworks MVC les plus répandus sont Cairngorm, Mate et PureMVC.
Suite à mon expérience sur Flex aussi bien sur des portails d'agence .Net  que des projets consistant à relier des écrans Flex à des applications COBOL AS400, je vais tenter (en m'aidant de l'excellent livre « Enterprise devlopment with Flex » chez O'reilly) de donner un aperçu de leurs caractéristiques et de faire ressortir leurs points forts et leurs points faibles.

Côté client

Introduction

On trouve plusieurs frameworks architecturaux autour des applications Flex. Ces frameworks ont pour objectif de structurer les applications afin d'augmenter la productivité et la maintenabilité. Ils s'appuient principalement sur le pattern MVC (Model View Controller).

Le pattern MVC a pour but de séparer la présentation de la logique métier.

Généralement, le modèle contient la logique métier, les vues présentent les données et le contrôleur met à jour le modèle en réponse à une action utilisateur.

Dans une application web, une action utilisateur peut entraîner l'appel à un service distant.

Le pattern Command est fréquemment rencontré pour gérer cet appel. Ainsi, lorsque l'utilisateur déclenche un événement, le contrôleur fait appel à la commande correspondante, qui effectue l'appel distant et met à jour le modèle.

Dans ce contexte, à quoi servent ces frameworks architecturaux ? Tout d'abord à structurer le développement des applications Flex, ensuite à assurer la communication entre les objets modèle manipulés par Flex et les services distants (et les implantations réelles, côté serveur de ces objets métiers).

Les frameworks MVC les plus répandus sont Cairngorm, Mate et PureMVC.

Suite à mon expérience en Flex aussi bien dans un contexte de portail Web et de services .Net  que des projets consistant à relier des écrans Flex à des applications COBOL AS400, je vais tenter (en m'aidant de l'excellent livre « Enterprise devlopment with Flex » chez O'reilly) de donner un aperçu de leurs caractéristiques et de faire ressortir leurs points forts et leurs points faibles.

Cairngorm

Cairngorm s'appuie sur un FrontController, un ServiceLocator et un ModelLocator pour implémenter le pattern MVC. Ces objets sont des singletons que le développeur doit instancier explicitement.

Cairngorm se base sur l'observation d'événements pour relier les vues et le contrôleur.

En effet, des événements particuliers (qui héritent de CairngormEvent) peuvent être déclenchés grâce au Disptatcher de Cairngorm (CairngormEventDispatcher, un autre singleton...) pour notifier le contrôleur. Ce  dernier va intercepter ces événements et exécuter la commande correspondante.

La commande va utiliser un Delegate pour effectuer l'appel distant et mettre ensuite le modèle à jour.

Lorsqu'une vue observe le modèle (par Data Binding par exemple) elle se met également à jour.

Ainsi le FrontController sert principalement à faire le lien entre les événements et les commandes.

Les commandes manipulent le modèle en s'appuyant sur un Delegate pour l'appel au service distant.

Le schéma ci-dessous illustre le fonctionnement de Cairngorm :

CairngormRemarque : depuis la version 3 Cairngorm est défini davantage comme un ensemble d'outils et de méthodologies que comme un framework MVC.

Les points forts:

  • C'est un framework populaire, beaucoup de développeurs le connaissent
  • Il permet de séparer les responsabilités
  • La centralisation des services permet de changer facilement de configuration (passer d'une configuration de tests à une configuration de production par exemple)

Les points faibles:

  • Il nécessite l'écriture d'un grand nombre de classes additionnelles. Cela prend généralement une bonne partie du temps sur un projet et en plus, ces classes sont souvent très redondantes. La moindre modification (ajout d'une commande ou d'une propriété) se traduit par  un travail plutôt fastitudieux impliquant des modifications sur différentes classes ou fichiers.
  • Il est basé sur des singletons globaux, ce qui complique la modularisation et couple fortement les objets.
  • Il ne permet d'associer qu'une seule commande par événement; la réutilisation de commandes ou la création de macro-commandes reste assez complexe malgré la fourniture d'un mécanisme adéquat.

Mate

Mate est un framework basé sur des événements et des tags MXML. Les applications Mate sont construites autour de l'invocation implicite causée par le déclenchement d'événements et l'injection de dépendance (injection des résultats dans les vues principalement). Cela rend les objets faiblement couplés.

L'invocation implicite est mise en œuvre par l'écoute d'événements décrits dans des objets de type EventMap. Ces événements sont des événements classiques de Flex et sont propagés de manière « Bubble ».

Mate offre donc une séparation flexible entre les vues et la logique métier de manière non intrusive. Il n'oblige ni à hériter d'objets ni à implémenter d' interfaces.

D'autre part Mate permet de construire des applications modulaires très facilement.

Le schéma ci-dessous illustre le fonctionnement de Mate :

Mate

Les points forts:

  • Mate est non intrusif
  • Il est basé sur des tags MXML et permet d'utiliser le modèle événementiel de Flex.
  • Il favorise le couplage faible entre les composants en implémentant l'injection de dépendances.
  • Il est bien documenté.

Les points faibles:

  • Il n'est pas encore officiellement en version release
  • Il n'implémente pas nativement la synchronisation des données (avec LCDS Data Management Service), il faut la gérer manuellement.

J'ai commencé à utiliser Mate en projet à la place de Cairgorm et pour le moment, la simplicité de mise en oeuvre de Mate me séduit beaucoup.

PureMVC

Comme Cairngorm, PureMVC s'appuie sur l'utilisation de singletons. Mais seule la Façade est instanciée explicitement par le développeur (c'est elle qui instanciera le modèle, la vue et le contrôleur).

La façade est le point central dans l'architecture de PureMVC. Elle va enregistrer des paires Notification-Command et il sera possible d'exécuter plusieurs commandes en réaction à une Notification.

Il s'articule principalement autour des notifications. Elles permettent le dialogue entre les différentes couches et vont transmettre les objets aux intercepteurs.

Les médiateurs vont faire le lien entre les vues et les autres couches de l'application. Ils vont créer des notifications à partir des événements et en réponse aux événements déclenchés par le modèle, et vont mettre à jour les vues correspondantes.

Les commandes sont utilisées pour effectuer des traitements métiers. L'utilisation de commandes permet de découpler la vue du contrôleur et de faire de la réutilisation. Elles sont déclenchées par les notifications.

L'utilisation de proxies est motivée par une volonté de découplage entre les modèles et les services. Cela permet par exemple d'appeler facilement des services Mock.

Enfin des Value Objects sont utilisés pour faire transiter des informations entre les différentes couches de l'application.

Le schéma ci-dessous illustre les mécanismes de PureMVC :

PureMVC

Les points forts:

  • Il est bien documenté
  • Il supporte la modularisation
  • Il est accessible aux développeurs qui ne souhaitent utiliser que l'ActionScript.
  • Il peut être utilisé avec d’autres technologies (les développeurs n’ont qu’un framework MVC à connaître)

Les points faibles:

  • Il n'est pas écrit spécifiquement pour Flex, il ne tire donc pas parti des fonctionnalités offertes par le MXML.
  • Il y a beaucoup de couches, qui sont très couplées.
  • Il demande de l'expérience pour les développeurs car il est complexe à appréhender
  • Il nécessite l'écriture d'un grand nombre de classes additionnelles
  • Il est basé sur un grand nombre de singletons dont l'appel encombre le code de l'application.

Côté Serveur

Introduction

Les applications Flex communiquent généralement avec un ou plusieurs serveurs pour échanger des données. Pour ce faire, plusieurs moyens sont disponibles :

  • les requêtes HTTP
  • les Web Services
  • le Flash Remoting

Flash Remoting est une technologie basée sur la communication HTTP de type requête/réponse. Il est nativement supporté par Flash Player, mais côté serveur, une « passerelle » est nécessaire afin d'assurer la réception et l'envoi de paquets AMF (Action Message Format) , de les convertir et de déléguer les requêtes vers les services appropriés.

LifeCycle, BlazeDS et GraniteDS sont les passerelles les plus populaires permettant de communiquer avec un serveur Java.

Ce paragraphe se limite à la description des caractéristiques des ces trois passerelles. Un article plus complet serait nécessaire pour avoir une vision précise des possibilités et des outils liés à la communication avec le serveur.

LCDS (Adobe LifeCycle Data Services)

LifeCycle est la référence d'Adobe, elle est complète… mais payante.

Elle inclut les fonctionnalités de Messaging, de Remoting, de gestion de données, de création de PDF. Elle gère les problématiques d'instances uniques au sein des applications, la synchronisation entre les clients et les applications et fournit un framework de résolution de conflit en temps réel.

Il est d'ailleurs intéressant d'étudier la nouvelle orientation prise par Adobe sur la version 3 de LCDS.

BlazeDS

BlazeDS peut être vu comme une partie de LifeCycle, Open Source et fournie par Adobe gratuitement.

BlazeDS inclut les fonctionnalités de messaging et de remoting et permet de faire du push en temps réel. Elle ne supporte pas RTMP (Real Time Messaging Protocol) et ne permet pas de gérer les problématiques de cycle de vie des données offertes par LifeCycle, ni de générer du PDF.

GraniteDS

Granite Data Services est une autre alternative open source à LCDS qui met l'accent sur l'intégration aux technologies Java EE, en incluant les systèmes de persistance (comme Hibernate et EJB3 avec un support complet du lazy loading).

De plus GraniteDS offre une interopérabilité avec les services comme :

  • les sessions bean EJB 3 (avec ou sans JBoss Seam)
  • les beans Spring avec la sécurité Acegi
  • les services Google Guice (avec la persistance Warp)
  • les services POJO
  • la Bean Validation (JSR 303)

Il supporte le Data Push et fournit un générateur de code (Gas3).

Par ailleurs, GraniteDS a été créé par deux développeurs java français.

Conclusion

La structuration des applications Flex paraît nécessaire pour assurer un bon niveau de maintenabilité et d'évolutivité.

L'utilisation d'un framework MVC comme ceux cités ci-dessus peut être une bonne réponse à ce besoin. Et même s'ils ne correspondent pas exactement, leur utilisation peut être adaptée grâce à de légères modifications. Par exemple on peut imaginer l'utilisation d'un événement générique avec Cairngorm afin de limiter le nombre d'objets à créer.

D'autres approches sont parfois rencontrées : certains développent un framework MVC simplifié conforme à leurs besoins, d'autres se passent de framework MVC en se contentant de définir des règles de codage, d'organisation de projets, à utiliser des librairies de composants ou utilitaires (comme le framework Clear Toolkit par exemple) ou encore à générer du code.

Concernant les échanges de données, le choix d'une passerelle AMF est très dépendant des besoins et des contraintes. Dans la plupart des cas BlazeDS et GraniteDS conviendront parfaitement.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.