Une fois, jai lancé un projet MVVM / WPF, qui a finalement été construit et déployé, et pour cela, jai beaucoup étudié le framework Caliburn.Micro MVVM. Le fait est que jai fini par ne pas utiliser Caliburn.Micro pour cela, et jai fini par implémenter moi-même certains concepts MVVM (en particulier, juste les ViewModelBase et RoutedCommand classes).
Maintenant, jai été affecté à un projet un peu plus grand dans le même esprit: un » mono-utilisateur Application de bureau hors ligne pour client riche « , pour ainsi dire, et jai décidé dutiliser Caliburn.Micro. Et cest là que commence mon » problème « .
Jai lu dans ce célèbre article de blog , dont le titre indique que » Si vous » utilisez MVVM, vous besoin de un cadre « , qui:
» Essayer de faire quelque chose comme MVVM sans framework est une énorme quantité de travail. Des tonnes de code en double, réinventant la roue et recycler les gens pour quils pensent différemment .
Au moins avec un cadre vous évitant le code en double et, espérons-le, vous navez pas à réinventer la roue – vous permettant de vous concentrer sur le recyclage des personnes. La partie de recyclage est généralement inévitable, mais un cadre fournit un code et une structure de plomberie, ce qui facilite le processus. »
Je serais daccord lors de la première lecture, mais mon expérience réelle avec Caliburn.Micro (CM) dans mon application actuelle , il y a une ignorance et une désorientation. Autrement dit, le cadre na pas du tout facilité le processus, bien au contraire. En lisant les exemples toujours répétés fournis par Rob Eisenberg dans la documentation plutôt (trop) informelle, et en essayant de déduire des modèles dutilisation à partir des échantillons alambiqués fournis, et leurs relations de classe et dinterface totalement indirectes, où les choses semblent être conçues pour fonctionner en fonction deffets secondaires, semblent humainement impossible à moins que vous ne soyez un génie chevronné (désolé pour la diatribe, mais je suppose que vous savez ce que je veux dire).
Sans oublier que tout scénario insignifiant ci-dessus semble impliquer des conteneurs IoC, ce avec quoi je nai jamais travaillé et qui semblent résoudre un problème que je nai peut-être même pas . Je nai pas envie de passer plus dheures de projet à apprendre ces choses au lieu de penser à mon problème et aux domaines dapplication. Je voulais juste une banane, mais CM ma donné un gorille (IoC) tenant un panier de bananes.
Maintenant que jenvisage de revenir à mon framework MVVM maison – composé uniquement de la poignée de MVVM- classes spécifiques que je veux réellement implémenter – je voudrais au moins donner une chance à CM, au cas où je perds quelque chose ici, ou tout simplement faire les choses » dans le mauvais sens » par pure inexpérience et ignorance. La question est donc la suivante:
Il existe un large consensus sur le fait que » les cadres rendent les choses plus faciles et plus naturelles « , mais sil marrive de vivre le contraire, cela signifie-t-il que je ne devrais pas utiliser le framework ou que jessaie de lapprendre de la mauvaise manière? indice que je ne devrais même pas utiliser un cadre en premier lieu? Ou existe-t-il un moyen » right » de comprendre comment utiliser CM pour le développement MVVM simple?
Commentaires
Réponse
Jai essayé CaliburnMicro et MVVMLight et lorsque vous utilisez Caliburn, je ressens vraiment ce que vous ressentez, je suis sûr que cela semble vraiment magique de pouvoir lier un contrôle à une propriété simplement en utilisant Name = » PropertyName » au lieu de lancien Text = » {Bind PropertyName} » mais à la fin Caliburn va bien trop loin pour faire cette chose magique . Quand quelque chose ne va pas, il est vraiment difficile de déboguer et daggraver les choses, ils ont beaucoup de façons de faire une chose.
En revanche, MVVMLight est vraiment mince. Lorsque vous lutilisez, vous réalisez probablement quil ressemble presque à 100% à votre framework MVVM, avec quelques fonctionnalités parsemées.
Je sais que cela ne répond pas à votre question » Comment NE PAS utiliser le framework » mais franchement, je ne peux pas vous recommander de suivre cette voie. Je pense que vous êtes simplement perdu parce que vous avez utilisé un framework complet au lieu dutiliser dabord un simple.
Commentaires
- Pensez-vous, alors, que je devrais au moins essayer dutiliser MVVMLight comme une sorte de » cure » de » Caliburn.Micro désorientation « ? Je jetterais sûrement un coup doeil si tel est le cas.
- @heltonbiker Certainement, essayez-le. Cest tellement plus simple que cela devrait au moins vous donner un bon pied sur MVVM Framework.
- Je suis daccord quil y a beaucoup trop de magie. Venant dun fond de c et dassemblage je suppose. E quelque chose ne fonctionnera ‘ que pour trouver que cela fonctionne à cause de la magie en arrière-plan. Impossible de déboguer et lorsque vous rencontrez des problèmes de performances, vous ne pouvez souvent pas faire grand-chose.
Réponse
Il est important de comprendre ce quest MVVM. Ce nest pas une fonctionnalité partagée que vous navez pas à réimplémenter (analyse dun fichier JPEG ou connexion à un serveur de base de données SQL donné), cest un modèle – un modèle sur la façon dont on peut choisir pour implémenter une interface graphique riche. Donc, si votre implémentation du modèle est simple et directe, je ne pense pas que vous ayez à ressentir de la honte en lutilisant plutôt quun cadre.
En effet, je crois que toute lidée des modèles en tant que cadres a allé beaucoup trop loin. Pour que quoi que ce soit soit un modèle, il doit sagir de la forme générale dune classe de solutions. Dans la mesure où il en est ainsi, il faut s’attendre à ce que les modèles doivent être adaptés aux systèmes qui les utilisent et vous ne pouvez pas le faire si vous essayez d’utiliser un modèle unique. Il serait beaucoup plus constructif de laisser l’implémentation des modèles au concepteur de l’application et de fournir des bibliothèques qui encapsulent les fonctionnalités plutôt que l’architecture.
Commentaires
- Ajouté à cela, MVVM tel que proposé par Microsoft (prêt à lemploi, WPF) manque beaucoup. Très frustrant même pour les programmeurs qui se considèrent (et à juste titre) comme des développeurs chevronnés. Des chaînes magiques, des exceptions obscures lors de lexécution, la plupart des éléments de base tels que la liaison dun groupe de boutons radio à une énumération ressemble à stackoverflow.com/q/397556/168719 – quoi les frameworks peuvent-ils faire? Ils doivent soit faire écho à ce niveau de complexité, soit essayer de fournir une abstraction vraiment épaisse dessus
- @KonradMorawski WPF en lui-même nest pas MVVM; vous pouvez faire du code derrière avec WPF, mais ce ‘ nest pas MVVM. Donc, si vous voulez faire WPF et MVVM, vous ‘ devrez utiliser un framework MVVM ou en implémenter un vous-même.
- @Andy bien sûr, mais il ‘ est sûr de dire que WPF est destiné à MMVM.Je ‘ fait référence à la fonctionnalité MVVM intégrée à WPF. Je sais que vous pouvez toujours faire du code derrière
- @KonradMorawski Vous pouvez utiliser WPF avec MVVM, et ils lont construit avec cette possibilité à lesprit, mais il ny a AUCUNE fonctionnalité spécifique à MVVM intégrée à WPF. Tout comme vous pouvez utiliser MVP avec WinForms, mais WinForms noffre rien spécifiquement pour utiliser ce modèle, cest à vous de décider.
- @Andy peut-être que nous ‘ discutons définitions maintenant. Ce que je veux dire, cest que toute la » colle » qui rend MVVM possible est déjà là – liaisons de données en XAML,
DataContextetc.
Réponse
Ma première expérience avec WPF a été dutiliser Caliburn. Micro donc cest probablement assez différent de la plupart des développeurs. Jai trouvé que WPF et Caliburn.Micro étaient une courbe dapprentissage assez raide, venant de WinForms, mais après une certaine expérience avec les deux, je les ai trouvés un plaisir à utiliser en paire. Travaillant actuellement dans une organisation différente où Caliburn.Micro nest pas utilisé, je trouve quil y a BEAUCOUP de code de plomberie en double, ce qui rend la base de code assez gonflée et inutilement complexe.
Je suis définitivement daccord quil y a des pièges avec Caliburn.Micro, qui peut compliquer le débogage, mais une fois expérimentés, ils risquent beaucoup moins dêtre à nouveau pénibles. La vitesse de développement accrue, le code plus propre et plus léger et le cadre global encourageant un meilleur MVVM en valent plus que la peine pour moi.
Caliburn.Micro ninvalide pas non plus le stock WPF – il sappuie simplement sur celui-ci, ce qui signifie que vous pouvez toujours utiliser les fonctionnalités de WPF si vous le souhaitez et utiliser Caliburn pour quelques bits si vous le souhaitez. Cest similaire à la façon dont TypeScript et JavaScript coexistent dans mon esprit.
Jutiliserais très certainement Caliburn.Micro dans tout nouveau projet WPF sur lequel je travaillerai à lavenir si jen avais la chance.
Commentaires
- Merci pour votre réponse. Deux ans plus tard, jai trouvé beaucoup plus facile d » accepter » ces cadres après avoir compris le concept de conteneurs dinjection de dépendances, que jai appris du excellent Mark Seeman ‘ s » DI dans .NET » livre.
Réponse
Pour quiconque arrive ici par frustration avec Caliburn.Micro, jetez un œil à ce cadre: Stylet
Il est inspiré de Caliburn.Micro, sauf quil supprime une grande partie de la magie qui vous laisse désorienté sur ce qui se passe. De plus, la documentation est rédigée dans un langage beaucoup plus simple sans supposer que vous vouliez parcourir le jargon technique. Beaucoup mieux pour les débutants.
De plus, Stylet adopte une approche ViewModel-First. Caliburn.Micro et beaucoup dautres frameworks adoptent une approche View-First, ce qui pose des problèmes délicats. Si vous maîtrisez déjà les principes SOLID et le code à motifs, vous trouverez probablement une approche ViewModel-First plus naturelle car elle part du principe que votre logique doit piloter le système – pas la vue.
EventAggregatorpour la messagerie etNotificationObjectpour a ViewModelBase et MVVM Light ‘ sRelayCommandpour les commandes. Limportant est didentifier les problèmes que le framework va résoudre pour vous et dutiliser uniquement ces solutions. Ne ‘ pas l’impression que vous ‘ êtes obligé d’utiliser toute la bibliothèque du framework.RelayCommand(car elle » lie » directement aux méthodes par convention, au lieu de se lier aux propriétés ICommand).RelayCommanddune autre bibliothèque si celle utilisée par Caliburn Micro ne fonctionne pas pour vous.