Comment choisir de NE PAS utiliser un framework (Caliburn.Micro, etc.) dans une application MVVM donnée?
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: j'ai fini pas en utilisant Caliburn.Micro pour cela, et j'ai fini par implémenter moi-même certains concepts MVVM (spécifiquement, juste les ViewModelBase et RoutedCommand Des classes).
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 fameux billet de blog , dont le titre dit que "Si vous utilisez MVVM alors vous avez besoin d'un framework ", cette:
"Essayer de faire quelque chose comme MVVM sans framework est un énorme travail. Des tonnes de code en double, réinventer la roue et recycler les gens pour penser différemment .
Au moins avec un framework, vous évitez le code en double et, espérons-le, vous n'aurez pas à réinventer la roue, ce qui vous permettra de vous concentrer sur le recyclage des gens. La partie de recyclage est généralement inévitable, mais un cadre fournit du code et une structure de plomberie, ce qui facilite le processus. "
Je serais d'accord sur la première lecture mais mon réelle expérience avec Caliburn.Micro (CM) dans mon réelle application 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 répétitifs 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 based sur les effets secondaires, semble 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 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 vivre le 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?
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 d'emprunter cette voie parce que 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.
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 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 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.
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 WPF stock - 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. C'est similaire à 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 travaillerai à l'avenir si j'en ai la chance.
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 en SOLID et code structuré, vous trouverez probablement une approche ViewModel-First plus naturelle, car elle considère que votre logique doit piloter le système - pas le vue.