Comment choisir de NE PAS utiliser un framework (Caliburn.Micro, etc.) dans une application MVVM donnée?

28

J'ai déjà lancé un projet MVVM / WPF, qui a finalement été construit et déployé, et pour cela j'ai étudié beaucoup de Caliburn.Micro MVVM Framework. Le fait est que j'ai fini par ne pas utiliser Caliburn.Micro pour cela et j'ai fini par implémenter moi-même certains concepts MVVM (en particulier les classes ViewModelBaseet RoutedCommand).

Maintenant, j'ai été affecté à un projet un peu plus grand dans le même sens: une «application de bureau hors ligne client riche utilisateur unique», pour ainsi dire, et j'ai décidé d'utiliser Caliburn.Micro. Et c'est là que commence mon "problème".

J'ai lu dans ce célèbre article de blog , dont le titre dit: "Si vous utilisez MVVM, vous avez besoin d' un framework", que:

«Essayer de faire quelque chose comme MVVM sans framework représente un travail énorme. Des tonnes de code en double, réinventant la roue et recyclant les gens pour penser différemment .

Au moins avec un framework, vous évitez le code en double et, espérons-le, n'avez pas à réinventer la roue - ce qui vous permet 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 d'accord sur la première lecture, mais mon expérience réelle avec Caliburn.Micro (CM) dans mon application réelle est d'être désemparée et désorientée. Autrement dit, le cadre n'a pas du tout facilité le processus, bien au contraire. Lire les exemples toujours répétés fournis par Rob Eisenberg dans la documentation plutôt (trop) informelle et essayer d'inférer les modèles d'utilisation à partir des échantillons fournis compliqués, et leurs relations de classe et d'interface tout à fait indirectes, où les choses semblent être conçues pour fonctionner sur la base de effets secondaires, semble humainement impossible, sauf si vous êtes un génie aguerri (désolé pour la diatribe, mais je suppose que vous savez ce que je veux dire).

Sans oublier que tout scénario ci-dessus semble impliquer des conteneurs IoC, ce que je n'ai jamais travaillé et qui semble résoudre un problème que je pourrais même pas avoir . Je n'ai pas envie de passer plus d'heures de projet à apprendre ces choses au lieu de penser à mon problème et aux domaines d'application. Je voulais juste une banane, mais CM m'a donné un gorille (IoC) tenant un panier de bananes.

Maintenant que j'envisage de revenir à mon framework MVVM homepun - composé uniquement de la poignée de classes spécifiques à MVVM que je veux réellement implémenter - je voudrais au moins donner une chance à CM, au cas où je perdrais quelque chose ici, ou simplement faire les choses "dans le mauvais sens" par pure inexpérience et ignorance. Et donc la question est:

Il existe un large consensus sur le fait que "les cadres rendent les choses plus faciles et plus naturelles", mais s'il m'arrive de faire l'expérience du contraire, cela signifie-t-il que je ne devrais pas utiliser le cadre ou que j'essaie de l'apprendre de la mauvaise façon? Y a-t-il un indice que je ne devrais même pas utiliser un cadre en premier lieu? Ou existe-t-il une "bonne" façon de comprendre comment utiliser CM pour un développement MVVM simple?

heltonbiker
la source
1
Personnellement, je sélectionne des éléments de chaque framework à utiliser pour des comportements spécifiques, et j'ignore le reste. Par exemple, j'aime utiliser Microsoft PRISM EventAggregatorpour la messagerie, et NotificationObjectpour un ViewModelBase, et MVVM Light RelayCommandpour les commandes. L'important est d'identifier les problèmes que le framework va résoudre pour vous et d'utiliser uniquement ces solutions. Ne vous sentez pas obligé d'utiliser toute la bibliothèque du framework.
Rachel
@Rachel J'avais l'intention d'utiliser cette approche avec Caliburn.Micro, mais je n'ai pas trouvé d' RelayCommandimplémentation (car elle "se lie" directement aux méthodes par convention, au lieu de se lier aux propriétés ICommand).
heltonbiker
Je n'ai jamais utilisé le framework Caliburn car je n'aimais pas à quel point il semblait lier les vues à la couche Model / ViewModel. Dans votre cas, je ne vois aucune raison pour laquelle vous ne pourriez pas utiliser un RelayCommandd' une autre bibliothèque si celle utilisée par Caliburn Micro ne fonctionne pas pour vous.
Rachel
@Rachel concernant "à quel point [caliburn] lie la vue à la couche MVM", que voulez-vous dire exactement? Quelle serait la manière «non calibrée» de lier ces couches de manière plus MVVM? (Je demande sincèrement car je ne sais pas actuellement).
heltonbiker
Honnêtement, je n'ai jamais utilisé Caliburn Micro, donc je pense que je suis un mauvais juge du cadre. Je me souviens avoir eu l'impression que la vue avait été créée en premier et était responsable de décider des objets code-behind, ce qui est un aspect que je n'ai pas aimé car je n'aime pas le développement de View-First. Un autre était les liaisons automagiques qui dépendaient de la façon dont vous nommez les composants XAML, car je pensais que cela liait trop l'interface utilisateur à la couche métier. J'ai cependant entendu de bonnes choses au sujet du cadre, et je ne suggérerais pas de l'éviter uniquement à mon avis. Essayez-le par vous-même et voyez si vous l'aimez :)
Rachel

Réponses:

16

J'ai essayé CaliburnMicro et MVVMLight et lorsque j'utilise Caliburn, je ressens vraiment ce que vous ressentez, sûr qu'il est vraiment magique de pouvoir lier le contrôle à la propriété simplement en utilisant Name = "PropertyName" au lieu de l'ancien Text = "{Bind PropertyName}" mais dans le fin Caliburn va beaucoup trop loin pour faire cette chose magique, quand quelque chose va mal, il est vraiment difficile de déboguer, pour aggraver les choses, ils ont beaucoup de moyens pour faire une chose.

Mais lorsque vous utilisez MVVMLight, il est mince, lorsque vous l'utilisez, vous vous rendez probablement compte qu'il est presque à 100% comme votre MVVM Framework, 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 car c'est juste faux, je pense aussi que vous êtes juste perdu parce que vous utilisez le framework complet au lieu d'utiliser simple Un premier.

kirie
la source
Pensez-vous, alors, que je devrais au moins essayer d'utiliser MVVMLight comme une sorte de "cure" de "Caliburn.Micro désorientation"? Je regarderais sûrement si c'est le cas.
heltonbiker
@heltonbiker Certainement, essayez-le. C'est tellement plus simple devrait au moins vous donner un bon point d'ancrage sur MVVM Framework.
kirie
Je suis d'accord qu'il y a beaucoup trop de magie en cours. Venant du milieu alternatif et de l'assemblage, je suppose. E quelque chose ne fonctionnera pas seulement pour le trouver en raison de la magie en arrière-plan. Impossible de déboguer et lorsque vous avez des problèmes de performances, vous ne pouvez pas faire grand-chose facilement.
roule
10

Il est important de comprendre ce qu'est MVVM. Ce n'est pas un peu de fonctionnalité partagée que vous n'avez pas à réimplémenter (analyser un fichier JPEG ou vous connecter à un serveur de base de données SQL donné), c'est un modèle - un modèle pour savoir comment on peut choisir d'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 besoin de ressentir de la honte à l'utiliser plutôt qu'un cadre.

En effet, je pense que l'idée des modèles en tant que cadres est allée beaucoup trop loin. Pour que quelque chose soit un modèle, il doit être la forme générale d'une classe de solutions. Dans ce cas, 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 à taille unique. Il serait beaucoup plus constructif de laisser l'implémentation du modèle au concepteur d'applications et de fournir des bibliothèques qui encapsulent les fonctionnalités plutôt que l'architecture.

Michael
la source
2
Ajouté à cela, MVVM tel que proposé par Microsoft (prêt à l'emploi, WPF) manque beaucoup. Très frustrant même pour les programmeurs qui se considèrent (et à juste titre) comme des développeurs chevronnés. Chaînes magiques, exceptions obscures lors de l'exécution, les choses les plus élémentaires telles que la liaison d'un groupe de boutons radio à une énumération ressemble à stackoverflow.com/q/397556/168719 - que peuvent faire les frameworks? Ils doivent soit faire écho à ce niveau de complexité, soit essayer d'en fournir une abstraction vraiment épaisse
Konrad Morawski
2
@KonradMorawski WPF en soi n'est pas MVVM; vous pouvez faire du code derrière avec WPF, mais ce n'est 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
1
@Andy bien sûr, mais il est sûr de dire que WPF est destiné à MMVM. Je fais référence à la fonctionnalité MVVM fournie avec WPF. Je sais que vous pouvez toujours faire du code derrière
Konrad Morawski
@KonradMorawski Vous pouvez utiliser WPF avec MVVM, et ils l'ont construit en pensant à cette possibilité, mais il n'y a AUCUNE fonctionnalité spécifique MVVM intégrée à WPF. Tout comme vous pouvez utiliser MVP avec WinForms, mais WinForms n'offre rien de spécifiquement pour utiliser ce modèle, c'est à vous.
Andy
3
@Andy peut-être que nous nous disputons sur les définitions maintenant. Ce que je veux dire, c'est que toute la «colle» qui rend possible MVVM est déjà là - liaisons de données en XAML, DataContextetc.
Konrad Morawski
7

Ma première expérience avec WPF a été d'utiliser Caliburn.Micro donc c'est probablement assez différent de la plupart des développeurs. J'ai trouvé que WPF et Caliburn.Micro étaient une courbe d'apprentissage 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 n'est pas utilisé, je trouve qu'il y a BEAUCOUP de code de plomberie en double qui rend la base de code assez gonflée et inutilement complexe.

Je suis définitivement d'accord qu'il y a des problèmes avec Caliburn.Micro, qui peuvent compliquer le débogage, mais une fois expérimentés, ils sont beaucoup moins susceptibles d'être à nouveau douloureux. La vitesse de développement accrue, le code plus propre et plus léger et le cadre général encourageant une meilleure MVVM valent largement la peine pour moi.

Caliburn.Micro n'invalide pas non plus le stock WPF - il se construit simplement dessus, ce qui signifie que vous pouvez toujours utiliser les fonctionnalités WPF si vous le souhaitez et utiliser Caliburn pour quelques morceaux si vous le souhaitez. Cela ressemble à la façon dont TypeScript et JavaScript coexistent ensemble dans mon esprit.

J'utiliserais certainement Caliburn.Micro dans tout nouveau projet WPF sur lequel je travaillerais à l'avenir si j'en avais l'occasion.

Ross
la source
3
Merci pour votre réponse. Deux ans plus tard, j'ai trouvé beaucoup plus facile «d'accepter» ces cadres après avoir compris le concept de conteneurs d'injection de dépendance, que j'ai appris de l'excellent livre «DI in .NET» de Mark Seeman.
heltonbiker
1

Pour tous ceux qui arrivent ici par frustration avec Caliburn.Micro, jetez un œil à ce framework: Stylet

Il est inspiré de Caliburn.Micro, sauf qu'il supprime une grande partie de la magie qui vous laisse désorienté par rapport à ce qui se passe. De plus, la documentation est écrite dans un langage beaucoup plus simple sans supposer que vous souhaitiez parcourir le jargon technique. Beaucoup mieux pour les débutants.

De plus, Stylet adopte une approche ViewModel-First. Caliburn.Micro et de nombreux autres frameworks adoptent une approche View-First, qui s'accompagne de problèmes délicats. Si vous êtes déjà très bon dans les principes SOLID et le code modelé, vous trouverez probablement une approche ViewModel-First plus naturelle car elle considère que votre logique devrait piloter le système - pas la vue.

JamesHoux
la source