C'est vrai mais un peu sévère je trouve. Tout ce que tu dis à beaucoup de sens mais il faut bien commencer quelque part. Nous utilisons pureMVC dans tout nos projets. pureMVC en soi n'a rien de transcendant mais il force à architecturer là ou d'autre oublierai même l'idée de réfléchir avant de coder.
Le changement de vocabulaire ne me semble pas être un problème non plus. Les notifications sont un moyen de communiquer entre le modèle et la vue, ni plus ni moins. Les events vont simplement servir dans chaque composant. Je trouve au contraire que cela clarifie grandement le problème. EN ce qui concerne le controller, l'utilisation de commande dans un FrontController est plutôt une bonne pratique dans le domaine de la POO me semble t-il. Quand aux mediators, c'est un design pattern connu qui a la même démarche que les MovieClipHelpers d'autre frameworks. En ce qui concerne les proxy, je trouve que c'est au contraire extrêmement bon, car encore une fois cela force à architecturer et facilite énormément le travail avec les devs php, asp ou autre. Le fait qu'il soit enregistrer dans un modèle est complètement transparent puisque tout passe par la facade. Pour les singleton "interne", il n'ont d'interne que le fait d'être instancier dans la face. J'avoue que je comprends pas. Cela me semble parfaitement intégré au concept de facade. Après effectivement, ce ne sont que des outils, et il est nécessaire d'y apporter sa propre touche, de bien comprendre la logique tout en gardant à l'esprit que c'est nous qui codons et pas le créateurs du framework. Cela doit également correspondre à un besoin. Lorsque l'on code dans une équipe avec des gens de différents niveau, que l'on s'adresse à des freelance ponctuellement, et que l'on a pas sous la main un tueur de ton envergure :) on doit se débrouillé. pureMVC ou autre framework maitrisé permet d'avoir une logique de développement dans une société. Lorsque le devs ont moins d'expérience cela permet facilement de leur expliqué les problèmes de ce qu'ils ont codé et de balisé le chemin. Donc bien au contraire je suis à 200% pour l'utilisation de tels outils. Cela nous a permis en interne de justifié la mise en place de réunion technique avant le départ de projet ( ce qui n'était pas le cas avant ), de bien baliser le développement, de mettre en place une surcouche générique qui nous correspond mieux, chargement de fichiers de configs systématique, écoute des notifications dans des écouteurs unique, gestion global des requête ou chargement de fichiers data, etc.... Visiblement tu parles d'un vécu bien particulier, et je prends toujours plaisir à lire tes coups de gueule car ils me permettent de prendre du recul, de me poser les bonnes question ; mais il ne faut pas généralisé, et plutôt souhaitez que les plus jeunes d'entre nous se servent de ce type d'outil car cela professionnalise grandement notre métier. En c, java, ou autre language bas niveau il y a beaucoup de dev avec 10 ans d'expérience qui ne savent pas ce que c'est qu'un modèle évenementiel, un model, un controller, une commande ou autre. Cela va dans le bon sens pour l'ActionScript, permet de réfléchir et de remettre son propre code en question, et ca cela n'a pas de prix. -----Message d'origine----- De : [email protected] [mailto:[EMAIL PROTECTED] De la part de zwetan Envoyé : mercredi 27 août 2008 13:43 À : FCNG Objet : [FCNG] flex cairgorm sur google code ca existe depuis longtemps mais je le mentionne ici comme le projet est open source http://code.google.com/p/flexcairngorm/ en gros des extensions pour le framework cairngorm j'ai pas regardé plus dans le detail que ca mais ca peut etre interessant a regarder avec cette logique "ok cairngorm est un debut de framework, comment des gens qui l'utilisent tous les jours peuvent l'etendre ?" et pour ca, ce projet est un bon exemple. et maintenant j'y vais de mon petit (bon ok gros) rant <rant> recemment j'ai bossé sur un projet qui utilise pureMVC meme concept juste un framework different sauf que voila là je vois bien la grosse faille ce genre de framework (et oui ca peut s'appliquer aussi a cairngorm) quand on utilise ce genre de framework, idealement c'est pour architecturer une application avec pour but - que n'importe qui dans la team bosse sur la meme structure - que une nouvelle personne arrivant sur le projet, parce qu'il connait deja l'architecture, puisse facilement d'adapter au code source et le comprendre mon premier grief contre pureMVC c'est le changement du vocabulaire le "model" devient un "proxy" la "view" devient un "mediator" le "controller" devient une "command" ca, désolé, c'est tres tres tres mauvais alors oui on peut me dire "mais meme si tu utilises un 'proxy' en vrai le proxy passe par un singleton interne 'model' blah blah blah" alors deja rien que le coup du "singleton interne" c'est une ENORME connerie, par definition un singleton ne peut pas etre interne, point ligne, y a meme pas a discuter (ou alors on peut discuter mais franchement bon courage pour me justifier ces singletons interne, car y en a pas 1 mais 3). Mon second grief envers pureMVC c'est que si idealement ca pourrait marcher dans la realité c'est tres different et en general ca tourne vite au bordel le framework force une architecture, ok mais les devs vont se baser sur ca pour developer le reste de leur code, seulement voila si ils plantent leur implementation et bah ils peuvent utiliser tout framework ou architecture qu'ils veullent leur code devient completement ingerable le fait d'utiliser pureMVC (ou autre framework) ne garantie pas une bonne architecture du code et en fait parce que les gens utilisent pureMVC (ou autre) ils pensent que par defaut quoiqu'il arrive que leur architecture de code est bonne, bah non pas forcément. exemple: ouais faisons un font-manager, youpihou on est dans pureMVC donc on va forcement bien le faire... bah non, quand on voit une class FontManager qui ne se base pas sur un model (ou proxy dans le cas de pureMVC), moi je dis "faute grave". le bon usage d'un framework comme pureMVC (ou autre) necessite des gens qui comprennent ce qu'ils font, pureMVC ce n'est que un tout petit point de depart, si on foire les regles et/ou la structure boom la jolie architecture s'ecroule. mon 3eme grief envers pureMVC c'est les notifications au lieu des events ah la celle la franchement c'est beau alors oui on peut me sortir "mais t'es pas obligé d'utiliser les notifications, tu peux n'utiliser que les events" ce a quoi je reponds "oui mais si un pignouf qui pense maitriser son code me fait un gros mixte cauchemardesque d'events mixés avec des notifications, on fait quoi ?" donc le probleme n'est pas vraiment qu'il y ait des notifications qui peuvent etre utilisées a la place des events ou switcher par des events, le probleme c'est qu'il y ait le choix le choix pour un dev experimenté c'est pas un probleme, mais pour un dev moins ou pas experimenté ca donne de grosses grosses boulettes dans le code, et a nouveau boom la jolie architecturee s'ecroule Et la le gros probleme c'est que aussi pourri soit l'implemenation du code au dessus de pureMVC les gars diront "oui mais c'est basé sur pureMVC donc est forcément bon" (en gros ils comprennent pas qu'ils utilisent tres tres mal l'architecture du truc) Mon grief final c'est le test du code source, normalement avec une bonne architecture ou micro-architecture, n'importe, ca devrait aussi aider a faire des unit tests plus facilement et plus structuré "youpi mon model est séparé donc je peux unit tester que le model, a part de la view et du controller" et bien non, je vois pas mal de gens bourrer le crane a d'autres sur "il faut utiliser pureMVC blah blah" mais je ne vois pas un seul unit test dans les parrages donc en conclusion du pureMVC mal utilisé + pas de tests ca donne un enorme bordel qui en fait crée plus de probleme que si pureMVC n'etait pas utilisé du tout. Donc la grosse faille de pureMVC, c'est que parce que une team utilise pureMVC ils en oublient completement la base du design de code (POO, et tout le toutim) parce qu'ils se focus tellement a essayer de suivre l'architecture de pureMVC qu'ils en oublie de juste bien structurer et ecrire leurs classes, mais comme ils se basent sur pureMVC ils pensent que rien qu'a cause de ca leur code est bien structuré. Ou pour le mettre dans un autre contexte, qlqn peut etre dans Java et ne pas faire de POO. </rant> zwetan --~--~---------~--~----~------------~-------~--~----~ Vous avez reçu ce message, car vous êtes abonné au groupe Groupe "FCNG" de Google Groupes. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement à ce groupe, envoyez un e-mail à l'adresse [EMAIL PROTECTED] Pour afficher d'autres options, visitez ce groupe à l'adresse http://groups.google.com/group/FCNG?hl=fr -~----------~----~----~----~------~----~------~--~---
