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 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?

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.

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.

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.

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.