Version imprimable
Bonjour,
Je voulais avoir vos avis sur Prism.
Est-ce performant et utilisable pour une application silverlight destinée aux entreprises ?
Car entre Prism, MVVM Light, etc.. on ne sait plus quoi choisir pour commencer à développer une application...
Des conseils ?
Merci
Prism est plus gros que MVVM light. Perso j'ai jamais utilisé Prism mais un formateur m'a dit un jour que Prism pouvait ruiner un projet si on commence sur la techno et qu'on y ajoute ce dernier.
Donc je connais pas tes connaissances sur SL, mais à éviter si tu débutes.
Prism effectivement, faut savoir le maitriser. Mais bien utilisé il donne de bons résultats! :)
Prism est un framework pour faire des applications composites. C'est donc tout à fait adapté pour des gros projets d'entreprises.
A titre personnel et professionnel j'utilise le framework nRoute que je trouve plus simple à mettre en oeuvre et qui fourni à peu de choses près les même fonctionnalités que Prism. Tu pourras trouver des informations sur ce dernier sur le site codeplex du projet (http://nroute.codeplex.com). Je suis aussi en train d'écrire une série d'article qui montre comment mettre en oeuvre certaines fonctionnalités telles que les commandes, les messages etc sur mon blog (http://blog.john-thiriet.com)
MVVMLight quant à lui suffit à la plupart des besoin des petits projets ou des projets de moyennes tailles mais là encore tout est affaire de goûts.
Prism, je trouve que c'est un trop grosse uzine à gaz pour la majorité des projets :)
Si je dois partir sur un Framework MVVM, je pars (toujours ;)) Si certains fonctionnalités sont manquantes, je les réimplémente en prenant les idées dans les autres frameworks (Cinch, Jounce, etc.) :)
Après, si je dois développer une application modulaires (composée de modules), je pars sur MEF, bcp plus simple à mettre en place que Prism.
+1Citation:
Envoyé par Thomas Lebrun
PRISM c'est bien, mais en general c'est sortir un tank pour tuer une mouche.
En général, UNITY, MEF + l'excellent MVVM Light suffit et c'est plus léger.
Hummm depuis la v4 je trouve prism assez simple à mettre en place.
Regardez les quickstarts il y a pas grand chose à faire pour le mettre en place ce n'est plus une usine à gaz comme avant.
Perso dans le cadre de grosse application pour pour travailler dans des grosses équipes, je recommande :ccool:
Pourquoi ? :DCitation:
Envoyé par anthyme
Je ne suis pas trop d'accord avec ce qui s'est dit ... Petit tour d'horizon des frameworks connus du marché :
nRoute : bon framework, mais développé par 1 seul gars, sans garanti sur les évolutions futures. Je l'ai essentiellement utilisé pour du WP7, et son kit de trigger/action/behavior est juste indispensable. Au-delà, on y trouve beaucoup de fonctionnalités ... pourquoi pas, mais ça part vraiment dans tous les sens !
MVVM Light : framework sympa, bien que personnellement, il ne m'a convaincu qu'à partir de la V4 (en preview actuellement). En gros, suffisant pour de petits projets. Pour du plus lourd ou modulaire, il vaut mieux passer à autre chose.
Caliburn : bon framework également, mais je n'ai pas assez approfondi pour donner un avis définitif. Assez complexe de rentrer dedans, bien que ça reprenne toujours les mêmes pratiques ...
Prism : on y arrive :) 2 ans que je l'utilise, 2 ans que je ne peux plus m'en passer. Prism, c'est du tout en un. Si tu veux un projet structuré, flexible et modulaire, c'est le top !
Evidemment, il faut du temps pour rentrer dedans. Il n'empêche que les concepts derrière sont simples, et en s'orientant vers les bons tutos, c'est vite assimilé (http://development-guides.silverbayl...verlight-Prism).
Comme je digère assez mal MEF (je n'aime pas l'approche décentralisée à coup d'attributs partout), autant dire que pour faire du modulaire avec Unity, Prism est bien pratique.
Seul bémol : les QuickStarts sont bien fichus, mais assez peu représentatifs d'applications réelles et parfois trop complexes à mon sens.
Il y a un petit temps déjà, j'ai développé une application de démonstration, sur base de Prism : http://happynet.codeplex.com (auto pub ^^).
En bref, ça dépend de ton besoin, de ton investissement, de la maturité de ton équipe et du sens du vent.
Personnellement, j'ai tendance à pencher pour du Prism à toutes les sauces, mais ça n'engage que moi et mes goûts (j'ai pas mal capitalisé dessus).
Je ne suis pas partisan de réinventer la roue, et Prism permet de vite retrouver ses marques d'un projet à un autre, tout en implémentant quelques patterns qui ont fait leurs preuves.
Si tu souhaites en discuter plus en détail, n'hésite pas ^^
@freezer08 : Tu es monde idole !! Toute l'info que je cherche depuis des semaines en un seul poste :ccool:
Content d'avoir pu me rendre utile :)
Tant que je suis au boulot, j'en profite pour partager 2 slides que j'avais fait en conclusion d'une présentation sur Prism :
[ Bilan ]
- Aide au développement
- Plein de concepts : on utilise ceux qu’on veut
- Modules, infrastructure, Shell
- Code architecturé, propre
- On garde ses marques
- Couplage faible
- Dépendances gérées via configuration
- Modularité
- Flexible, léger, chargement à la demande
- Pattern MVVM & Commandes
- Communication découplée et facilitée
- Augmente la testabilité
[ Toujours adapté ? ]
- Quid des petits projets ?
- Un projet est-il petit et simple à tout jamais ?
- Modularité importante ?
- MVVM Light Toolkit
- Trop compliqué ?
- Rien de conceptuellement complexe
- Une fois compris, code plus clair
- Trop long à mettre en place ?
- Plein d’interfaces, vues, vues-modèles …
- … mais gains en testabilité & databinding puissant
- dll Prism grossissent mon app ?
- Zippées => ~100ko
- Chargement dynamique de modules, à la demande
Hello,
Je me permettrais de faire une remarque sur cette partie:
Pris en dehors du contexte, on pourrait tout à fait attributé ce bilan au couple MVVM Light + MEF + Unity.Citation:
Envoyé par freezer08
Ainsi, on se rend compte que ce n'est pas spécifique à Prism ;)
Parfois, j'aurais tendance à dire trop de concepts, d'où le termes d'uzine à gaz que j'ai employé dans mon précédent post.Citation:
Plein de concepts : on utilise ceux qu’on veut
Prism est in bon framework mais c'est un peu sortir un char d'assault pour ouvrir une porte.... De plus, il impose aux développeurs de devoir respecter une certaines méthodologie pour que cela fonctionne.
MEF, qui se base effectivement sur des attributs (donc plus simple à mettre en oeuvre), apportera la fonctionnalité de modularité à une application, sans pour autant imposer des contraintes (parfois lourdes) en termes de développement :)
Je ne suis pas du tout d'accord avec toi thomas.
Ok avec MVVMLight MEF et Unity on peut faire beaucoup de choses, mais ce sont des technologies indépendantes qui pourront être assemblées d'autant de façons qu'il y a des développeurs qui choisissent ces Frameworks.
PRISM à l'avantage d'apporter une façon "standard" (et la plus rependu en application composite) d'architecturer une application.
Un développeur connaissant prism qui récupére une application prism aura moins de surprises que s'il y a des briques custom (mal?) fait.
On arrive un peu sur l'histoire de "réinventer la roue".
Ca tombe bien, le but d'un débat, c'est de débattre ;)Citation:
Envoyé par anthyme
Hum... oui et non: au final, il n'y a pas 36 façons de faire cohabiter ces éléments ensemblesCitation:
Ok avec MVVMLight MEF et Unity on peut faire beaucoup de choses, mais ce sont des technologies indépendantes qui pourront être assemblées d'autant de façons qu'il y a des développeurs qui choisissent ces Frameworks.
Prism apporte une façon d'architecturer une application, certes. De là à dire que c'est une façon standard ou la façon la plus répandue, je ne suis pas forcément d'accord. Prism est un framework qui regroupe différents concepts: ce sont ces concepts qui, une fois réunient et utilisé par le plus grand nombre, te permettent d'obtenir un standard. Cependant, rien n'oblige à utiliser PRISM pour faire cette "réunification".Citation:
PRISM à l'avantage d'apporter une façon "standard" (et la plus rependu en application composite) d'architecturer une application.
Attention, ton constat part du principe que le développeur connait déjà Prism. Mais tu peux inverser la situation: un développeur qui ne connait pas Prism aura beaucoup de surprises s'il se retrouve sur un projet l'utilisant.Citation:
Un développeur connaissant prism qui récupére une application prism aura moins de surprises que s'il y a des briques custom (mal?) fait.
Je vais parler de mon expérience personnelle, afin que les gens comprennent un peu mieux mon point de vue. A titre professionnel, je dispose de 3 casquettes: Consultant, Architecte et Développeur.
Constats sur les missions sur lesquelles je suis intervenu en temps que Consultant:
- Certains projets utilisaient Prism, d'autres pas, certains avec MVVM, d'autre avec de l'IoC, sur des petits, moyens ou (trèsà gro projets, setc... Bref, un peu de tout. Ce qu'il en ressort, c'est que les développeurs qui ont eu à utiliser Prism ont tous fait les mêmes réflexions: c'est une grosse artillerie pour pas forcément grand chose, qui apporte souvent plus de problèmes que cela veut en résoudre (memory leak avec des composants externes, events déclenchés de toute part, etc.) + il l'aurait pas utilisé, il n'aurait pas vu la différence (si ce n'est peut-être moins de problèmes)
Constats sur les missions sur lesquelles je suis intervenu en temps qu'Architecte:
- Là encore, du petit au gros projets mais un constat clair: je n'ai jamais eu besoin de Prism :) Certes, certains des projets utilisaient des fonctionnalités similaires à ce que l'on trouve dans Prism mais celles-ci ont été réimplémentées. Ainsi, en partant du trio MVVM Light + MEF + Unity, on disposait déjà de très bonnes bases, qui n'imposaient pas de contraintes particulières et qui avaient le mérite de pouvoir proposer une architecture claire et abordable par n'importe quel développeur.
Constats sur les missions sur lesquelles je suis intervenu en temps que Développeur:
- Je suis les concepts mis en place par l'architecte. Dans la majorité des cas, tout se passe bien mais il arrive (souvent ?) qu'on me demande de retoucher à des partie de Prism parce que la gestion des events ne convient pas, n'est pas optimisée, etc. Ou alors, je passe moi même un bon moment à essayer de comprendre ce qui a été fait avant de faire quoi que ce soit (je ne suis pas forcément un expert "es" Prism mais tu l'as dit toi même, normalement, la mise en place de Prism est toujours la même donc si même moi qui ait un peu l'habitude de Prism, je galère, j'imagine le développeur débutant)
Je ne remet pas en cause Prism, son intérêt, son utilisation ni rien. Je dis simplement que pour la majorité des projets, il est bien trop complexe ou démesuré. Je recommande toujours, pour l'architecte, d'imaginer son projet avec des briques plus simple MVVM Light + MEF + Unity et de voir si tous ces besoins sont couverts. Si oui, alors tant mieux ! Sinon, j'incite à regarder autour de soi si le besoin manquant n'a pas été couvert dans un Framework autre (ce qui est souvent le cas). A partir de là, 2 possibilités: "piquer" l'implémentation du besoin pour l'insérer dans son propre Framework ou alors directement partir sur le nouveau Framework, à condition que celui-ci remplisse correctement tous les autres besoins :)
J'ai essayé PRISM+MEF et c'est méga casse gueule :aie:
Par contre, PRISM+Unity ca a été mon choix d'implémentation sur ce que je suis entrain d'architecturer et à part un petit temps de reflexion sur l'intégration de la navigation du toolkit avec prism, je trouve ca assez chouette!
Bon après faut dire que j'ai travaillé avec freezer08 sur la démo TechDays de notre boite "comment mettre en place une archi Prism" et que j'ai pas trop d'experience sur les autres framework donc mon jugement est un peu biaisé :)
J'ai corrompu ton coeur pur et innocent Nath, désolé ! :p
Plus sérieusement, ce que j'aime dans Prism, c'est avant tout les principes qu'il met en avant, et la façon de faire. En gros, ça pose les bases de la définition d'un module et argumente le besoin du découplage.
Dans mon expérience personnelle, j'ai aussi eu tendance à prendre des morceaux à droite à gauche, et les assembler pour façonner un framework maison qui me plaisait. A force, j'ai surtout constaté que je pondais quelque chose d'indigeste, à ma façon, qui me convenait, qui était peut-être sexy sur le papier, mais qui manquait de cohésion et clarté.
Là, on nous fournit un framework labellisé Microsoft, avec un suivi assuré, de la doc, des quickstarts, une méthodo et plein de concepts pour pondre une application propre.
Pour l'aventure MEF + Unity, je ne conseille pas. C'est un joyeux casse-tête, même à l'aide d'un certain MEF Contrib.
Pour le reste, encore une fois, l'outil ne façonne pas votre construction. On peut très bien faire n'importe quoi avec du Prism, tout comme on peut faire n'importe quoi avec du MVVM Light. Sauf que dans un cas, on a un guide assez structurant, dans l'autre, on nous laisse très (trop?) libre.
Quoiqu'il arrive, Prism ou pas Prism, je recommanderai toujours à un novice qui a envie d'apprendre d'y jeter un coup d'oeil. C'est quand même un joyeux condensé de design patterns en tout genre qu'il est intéressant de croiser sur sa route. Et ça donne mine de rien quelques clefs en main pour appréhender le monde complexe de l'architecture ...
Tout à fait d'accord ! :) A un petit bémol prêt: avant de lui conseiller de regarder Prism, je lui conseillerais de regarder les différents patterns qui peuvent exister, pour qu'il ne soit pas trop perdu dans la lecture d'une application PrismCitation:
Envoyé par freezer08
@Nathanael: Avoue que t'es de mêche avec freezer08 :aie:
Pour prendre Prism en main j'ai d'abords lu le userguide très bien fait (300pages) puis regarder les samples. Ca passe bien.
Par contre je ne comprend pas ... Pourquoi utiliser MEF et unity en même temps ?
Oué! Comme dit plus haut, on fait tous les deux de la veille technos et on bosse sur les applis référence de So@t :DCitation:
Envoyé par Thomas Lebrun
Cela dit, j'avais déjà fait du Prism avant d'arriver chez So@t...
La doc s'est largement améliorée depuis la v1, c'est effectivement très accessible.Citation:
Envoyé par anthyme
Utiliser MEF + Unity, c'est combiner la force des 2 outils. MEF est orienté plug-in / découverte dynamique de composants, alors que Unity a une approche de centralisation de la configuration, souvent plus simple.
Quelques différences en résumé :
- Unity
- Résolution de classes concrètes sans enregistrement
- Résolution de génériques
- Interception
- Nombreux retours d'expérience
- MEF
- Découverte d'assemblies / XAP à la volée
- Recomposition à chaque nouvelle découverte
- Exporte automatiquement les types dérivés
- Livré avec Framework .NET
Après, on se heurte à la problématique : est-ce que MEF doit contenir Unity, ou l'inverse ?
MEF Contrib donne quelques réponses, mais ce n'est pas simple ... (cf. http://mefcontrib.codeplex.com/wikip...%20Integration)