J’ai quelques questions sur le modèle MVVM

Je m’appelle Jesús (Espagne), je suis développeur .NET et je viens de découvrir ce formidable site Web il y a quelques jours.

J’ai quelques questions sur le modèle MVVM et je serai heureux si vous pouvez y répondre.
J’ai commencé à utiliser WPF il y a trois mois et j’ai appris le modèle MVP.
MVP est tellement bon parce que vous pouvez très bien structurer l’application.

J’ai commencé à voir MVVM partout, mais tout le monde utilise le modèle de sa propre manière.
Chaque blogueur parle de MVVM dans les blogs de WPF, mais chaque implémentation est distincte.

Je me concentre maintenant sur les implémentations qui utilisent la boîte à outils MVVM sur CodePlex, mais j’ai des questions et je ne trouve pas trop d’informations.

Je pense que MVVM est une variante de MVP.
Avec MVP, chaque vue a un présentateur qui fait le travail de la vue.
Dans MVVM, c’est la même chose mais en utilisant des commandes chaque fois que vous le pouvez.

J’ai aussi vu que si vous avez besoin d’un événement, c’est comme avec MVP; déléguer l’événement au présentateur / View-Model, c’est-à-dire s’il ne s’agit pas d’un travail pour la vue (telle que la mise à jour de l’interface utilisateur).

D’autre part, View-Model n’a pas de référence View, je dois donc jouer plus fort avec les liaisons de données.
Vous devez utiliser les DelegateCommands (qui sont la même chose que RelayCommands, non?).

Uhm … d’autres questions … Est-il prudent d’utiliser le même modèle de vue avec deux vues / contrôles utilisateur?

Oh … j’ai rencontré un problème hier lorsque je jouais à MVVM.
J’ai créé CommandReference de ma commande pour la liaison de clé et j’ai affecté cette référence à la propriété de commande de mon bouton. CanExecuted bien, CanExecuted fonctionné la première fois, mais n’a pas mis à jour la propriété IsEnabled lorsque CanExecuted était à true. Je l’ai corrigé en liant la commande directement au bouton et en n’utilisant pas la référence. La question qui se pose est la suivante: pourquoi un code lie la référence aux objects et pourquoi un autre code lie-t-il directement la commande?

Quels éléments liés à MVVM devrais-je apprendre? (J’ai vu hier un comportement appelé comportement attaché mais je ne sais pas ce que c’est).

Je suis en train de réécrire une application de prise de notes que j’ai développée avec MVP, mais maintenant avec MVVM. Je vais remplacer les événements par des commandes (à l’aide de DelegateCommand), éliminer les références de vues sur View-Model et je pense que c’est tout parce que les exemples que j’ai vus de MVVM ressemblent beaucoup à MVP.

Bien, j’apprécierais que vous me signaliez tous les malentendus que j’ai avec ce schéma.

Merci et à l’avenir j’aiderai les prochains novices MVVM 🙂

Wow, je vais essayer de répondre à autant de vos questions, qui n’impliquent pas une technologie ou un cadre spécifique, autant que possible … désolé si j’en manque quelques-unes (des points centrés aideraient)

  • MVVM n’est pas nécessairement une variante de MVP. MVP lui-même est un terme ambigu et chargé. Martin Fowler l’a rendu justice en le scindant en deux schémas . MVVM est autonome, mais partage certains concepts avec les modèles MVP. Comme tous les modèles d’interface utilisateur, il cherche à séparer autant que possible la logique d’affichage de la logique métier. Ce qui différencie MVVM de MVVM, c’est qu’il crée un modèle uniquement à des fins de présentation (ou un modèle de présentation ). Cela diffère de la façon dont les modèles MVP résolvent le problème de séparation.
    • Vue passive – Avec la vue passive, la vue ne voit jamais le modèle.
    • Contrôleur de supervision – MVVM est beaucoup plus proche du modèle de contrôleur de supervision que de la vue passive. La seule différence réelle ici pourrait être que le MVVM crée explicitement un modèle uniquement pour la vue (d’où le terme “View Model”)
  • Le ViewModel n’a pas de référence à la vue, car il sert de modèle pour les données de la vue. C’est une abstraction appropriée. Si elle faisait également référence à la vue, vous auriez une dépendance à double sens qui créerait un couplage supplémentaire. De plus, le modèle de vue lui-même n’a pas de raison réelle de connaître la vue. Son seul travail consiste à extraire le modèle (le modèle économique actuel) de la vue.
  • DelegateCommands vs. RelayCommands – Je pense que la technologie est spécifique à la technologie, donc je ne peux pas vraiment répondre à cette question.
  • Vous ne devez pas concevoir un ViewModel pour plus d’une vue. Cela ne crée de la coplexité que si vous modifiez une vue, vous devrez rechercher quels ViewModels pourraient être affectés et les modifier. Cela pourrait éventuellement entraîner un effet de cascade. Votre comportement doit être dans le modèle d’entreprise, pas dans le ViewModel. Par conséquent, le ViewModel doit uniquement contenir une logique de traduction et de gestion des événements.
  • Cependant, il serait judicieux d’avoir un rapport ViewModel / UserControl de 1: 1, car UserControls est censé pouvoir fonctionner comme des unités autonomes sur votre écran.
  • En ce qui concerne les autres questions spécifiques à la technologie, désolé, je n’ai pas de réponse. Je peux toutefois vous suggérer de lire attentivement les liens que j’ai inclus pour la vue passive , le contrôleur de supervision et le modèle de présentation . Elles fournissent un contexte aux modèles d’interface utilisateur et sont neutres en technologie.

Il est important de garder à l’esprit que, bien que MVVM soit adapté à la résolution des problèmes posés par l’adoption de WPF, il ne s’agit pas d’un modèle technologique spécifique. Si vous plongez trop dans une mise en œuvre spécifique sans comprendre la philosophie sous-jacente, vous risquez de commettre de très grosses erreurs très tôt et de ne les découvrir que plus tard. Malheureusement, MVVM n’est pas un modèle bien documenté, et vous avez raison lorsque vous déclarez que chacun a sa propre idée de ce qu’il en est.

Ce n’est pas un modèle révolutionnaire (il existe depuis des années sous différents noms), mais la liaison de données de WPF en fait une solution viable, ce qui lui confère une nouvelle popularité. C’est un bon modèle, mais ce n’est pas une docsortingne. Abordez chaque “dicter” avec le scepticisme approprié.

MODIFIER

@ Micahtan a raison de dire que la liaison de données est une pièce très importante dans WPF. J’ai déclaré que la liaison de données de WPF active la solution MVVM, mais que la liaison elle-même est très puissante, ce qui explique pourquoi l’adoption de MVVM se développe plus rapidement que la documentation qui l’entoure.

Vous n’avez pas réellement besoin d’utiliser RelayCommand. Tout ce que vous avez à faire est d’implémenter l’interface ICommand sur un object. Dans le cadre principal de SoapBox , j’ai défini une interface appelée ICommandControl et tous les boutons ViewModels, etc. implémentent cela. Il existe également une classe AbstractCommandControl que vous pouvez dériver pour l’implémenter.