J’ai redécouvert récemment PureMVC qui est sorti officiellement cet été et qui est déjà en version 1.6. C’est carrément top ! Rendez vous sur le site (pureMVC.org).
Pour ceux qui ne connaissent pas encore PureMVC, il s’agit – comme son nom l’indique – d’un framework MVC, et je dirais même que c’est un « pur framework ».
Je l’ai utilisé pour porter une (petite) appli Cairngorm en cours de développement. Ca m’aura pris un week-end, et au final j’ai un code dont je suis bien plus satisfait qu’avant, avec une architecture que je trouve mieux structurée et plus puissante.
J’avais parlé d’une simplification de Cairngorm, mais en fait comme je ne suis pas pleinement satisfait du résultat, je ne l’ai pas publié.
J’en arrive d’ailleurs à penser qu’il vaut parfois mieux changer de framework que d’essayer de « simplifier » ou de « patcher » notre cher « vieux » Cairngorm, qui nous aura rendu bien des services, et nous en rendra encore certainement.
Petite mise à jour: nous venons de publier des outils d’aide au développement des applications MVC, pour Cairngorm et pour PureMVC. Ces consoles interactives pourront vous aider à mieux comprendre ce qui se passe au niveau du framework, n’hésitez donc pas à les télécharger (c’est gratuit) et à les utiliser:
Comparaison rapide et un peu lapidaire de Cairngorm et PureMVC
A la différence de Cairngorm, PureMVC ne se contente pas de fournir quelques classes utilitaires simples (le ServiceLocator, le Controleur) et des bonnes pratiques d’utilisation.
En effet, il structure plus rigoureusement, et de manière plus souple et plus évolutive, les données, les commandes, les événements et les vues. Si l’on suit les bonnes pratiques recommandées en s’inspirant des exemples fournis, on obtient rapidement une application réellement bien architecturée, et avec moins de code technique à écrire qu’avec Cairngorm
De plus Cairngorm est peu évolutif, contient des manques (par exemple les méthodes result qui ne renvoie rien) et pour dire franchement il faut le patcher pour lacher la puissance des actions. Cairngorm encourage également la pratique du « modèle fourre-tout », dans lequel on stocke plein de variables globales, et on se retrouve assez vite avec un capharnaüm de données dans ce singleton….
Avec PureMVC, l’approche est un peu différente ce qui évite les écueils ci-dessus et le framework est réellement bien écrit, et très évolutif.
Que choisir alors, Cairngorm ou PureMVC ?
Je ne dis pas qu’il faut porter les applis Cairngorm en PureMVC, ni qu’il faut arrêter d’utiliser Cairngorm, ni que Cairngorm est malcommode ou peu pratique.
Je dis par contre que pour des projets d’envergure, destinés à perdurer, à être développés en équipe, PureMVC sera un choix mieux adapté que Cairngorm.
De plus, même pour des projets plus simples, l’usage de PureMVC sera plus formateur sur les bonnes pratiques et sur le MVC que Cairngorm.
Un seul défaut pour ceux qui ont du mal avec l’anglais: toute la doc est en anglais et n’est pas encore traduite. Mais elle vaut le coup d’être étudiée et lue, car elle est complète et bien écrite.
Le site comporte également des exemples simples à étudier pour se lancer dans l’utilisation de PureMVC.
En conclusion, je dirais que l’étude de PureMVC est un (petit) investissement qui peut en valoir la peine, et un bon apprentissage des patterns du MVC.
Et maintenant la petite intro technique
Pour vous présenter ce framework, permettez-moi de vous retranscrire en français l’introduction à PureMVC qu’on trouve dans la documentation en ligne sur le site
L’objectif de PureMVC est simple: nous aider à séparer l’application en trois tiers distincts qui sont le Modèle, la Vue et le Controleur. Jusque là, rien de bien nouveau, sauf que là c’est vraiment bien pensé.
Les éléments principaux du système sont donc:
- Le Modèle: il contient des références nommées vers des objets « Proxy ».
- Les Proxys et les VO: Le code d’un Proxy manipule le modèle de données (incluant celles obtenues par des services remote), qui sont toujours stockées dans des ValueObjects (VO)
- La Vue: elle contient des références vers des objets « Mediator ». Le code d’un Mediator prend en charge et administre des composants visuels (comme des composants MXML). Il y ajoute des EventListener, envoie et reçoit des Notifications (globales) depuis et vers le reste du système. Il manipule donc directement l’état des composants qu’il administre. Cela sépare clairement la définition de la vue de la logique qui la contrôle
- Le Controleur: Il maintient une table de commandes nommées. Les commandes sont stateless et sont crées uniquement lorsqu’elles sont requises.
- Les Commandes: elles peuvent obtenir des références sur les Proxies et les manipuler, elles peuvent aussi envoyer des Notifications, exécuter d’autres Commandes, et elles sont souvent utilisées aussi pour orchestrer des activités complexes ou globales au système, telles que le démarrage et l’arrêt d’une application
- La Facade: c’est également un Singleton, qui initialise les acteurs fondamentaux du système (Modèle, Vue et Controleur). Il offre un emplacement unique d’où accéder à toutes leurs méthodes publiques.
- Observateur et Notifications: la circulation des évènements principaux entre les acteurs du noyau s’effectue par une implémentation autonome d’un pattern « Observateur », avec des évènements spécifiques qui sont ici des Notifications. Cela rend le modèle indépendant du système EventObserver de Flex et AS.
Mode de fonctionnement général
- Les Notifications peuvent être utilisées pour déclencher l’exécution des commandes (comme dans Cairngorm où l’on dispatch un évenement associé à une commande)
- Les commandes sont associées à un nom de Notification (dans la Façade concrète) et elles sont automatiquement déclenchées par le contrôleur lors de la réception de leur Notification associée.
- Typiquement, les Commands orchestrent les interactions complexes entre la Vue et le Modèle, tout en en sachant aussi peu que possible sur chacun d’entre eux
- Les Mediateurs envoient et reçoivent des Notifications (celles auxquelles ils se sont « abonnés »)
- lorsqu’ils sont enregistrés dans la Vue, les médiateurs sont interrogés pour connaître les Notifications qui les interessent
- Plus tard, lorsque une Notification du même nom est envoyé par un acteur quelconque du système, les Médiateurs intéressés seront notifiés et leur méthode handleNotification sera appellée, avec une référence vers la Notification elle-même
- LesProxys envoient des Notifications mais n’en reçoivent pas
- Les Proxys peuvent envoyer des Notifications pour des raisons variées, telles qu’un RemoteProxy devant alerter le système qu’il a transféré de nouvelles données, ou encore un Proxy qui s’occuperait lui-même de ses mises à jour. C’est évidemment différent du système de bindings systématisé par Cairngorm avec les ModelLocator.
- Les proxys ne doivent pas recevoir de Notifications, car ce serait le coupler trop fortement avec le Contrôleur et la Vue?
Pour en savoir plus, il faudra pour l’instant aller voir directement la doc en ligne:
Bon MVC à tous !