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 !
Merci pour cet article, très intéressant. Voila qui remet en cause mon l’architecture MVC de mon projet…
Ton article est tres interessant et ce framework a l’air tres complet. Meme si je n’ai pas eu le temps de l’essayer, une question me taraude : Tu te plaignais de Cairngorm en disant que beaucoup de fichiers devaient etre ecrits pour faire une action simple, ce qui faisait baisser la productivite. Ce framewrok a l’air encore plus lourd que Cairngorm a ce niveau. Suis-je dans l’erreur ?
Merci
Merci pour ton commentaire.
C’est sur qu’il faut écrire du code, et comparé à Cairngorm, on se retrouve effectivement avec plus de classes (dont les rôles et responsabilités sont bien réparties).
Ca peut être un frein à l’adoption de ce framework, mais il se pourrait aussi que des plugins FB voient le jour pour automatiser la création de certaines classes
Merci pour cet article.
Nous utilisons le framework: ServeBox
http://sourceforge.net/projects/sbasfoundry/
Il semble très proche de PureMVC, et nous permets une décomposition parfaite des éléments de l’application.
A+
Bonjour,
Merci pour tes éclairages.
De quoi mettre de l’eau à ton moulin :
http://www.sephiroth.it/weblog/archives/2007/10/flex_frameworks.php
Voici d’autres avantages de Puremvc par rapport à Cairngorm qui font la différence.
Puremvc permet de mettre minimum de code dans les “view”, d’ou une centralisation du code encore plus grande.
Le fait de pouvoir envoyer des notifications depuis les Mediators augmente la puissance (à la suite d’un autre evenement en cours de traitement par ex.)
On arrete de mettre des [Bindable] partout.
…
Disons que pureMVC (développé par une grosse société partenaire d’Adobe) respecte beaucoup plus que cairngorm (développé par Adobe depuis pas mal de temps) les design patterns. Le code en résultant est vraiment bien structuré et très logique et la place prise par le framework est assez faible.
En fait il faut surtout considérer ces frameworks comme des règles pour coder et on y trouve une efficacité dans le travail en équipe sur des projets faisants intervenir des modèles complexes.
Et puis y a rien d’extraordinaire niveau code, par exemple la classe model.as de pureMVC ne fait que quelques lignes qui permettent de stocker un tableau d’objets Proxy (qui eux permettent de manipuler les données). Le controler lui contient juste un tableau d’objets Command etc etc … La classe Proxy fait 10 lignes à peine !
Donc pour ma part, je considère vraiment ces frameworks comme des règles de conduite à suivre pour assurer une bonne périnité au projet et pour favoriser une homogénéité du code lors du travail en équipe.
[...] Flash / Flex 2 m’a permis d’appréhender le formidable framework PureMVC dont parle KapIt dans son blog. Je vous en parle très prochainement, [...]
[...] Quel choix avez vous fait ? Caingorm ou pureMvc ? [...]