Aide avec MVVM complexe (plusieurs vues)

J'ai besoin d'aide pour créer des modèles de vue pour le scénario suivant:

Des données profondes et hiérarchisées
Vues multiples pour le même ensemble de données
Chaque vue est une vue unique, à changement dynamique, basée sur la sélection active
Selon la valeur d'une propriété, affichez différents types d'onglets dans un contrôle d'onglet

entrez la description de l'image ici

Mes questions:

Dois-je créer une représentation de modèle de vue pour chaque vue (VM1, VM2, etc.)?

1. Yes:
    a. Should I model the entire hierarchical relationship? (ie, SubVM1, HouseVM1, RoomVM1)
    b. How do I keep all hierarchies in sync? (e.g, adding/removing nodes)

2. No:
    a. Do I use a huge, single view model that caters for all views?

Voici un exemple d'une vue unique

Figure 1: plusieurs vues mises à jour en fonction de la pièce active. Contrôle de l'onglet Avis

entrez la description de l'image ici

Figure 2: Différente salle active. Plusieurs vues mises à jour. Les éléments de contrôle d'onglets ont été modifiés en fonction de la propriété de l'objet.

entrez la description de l'image ici

Figure 3: type de sélection différent. Modifications de la vue entière

entrez la description de l'image ici

wpf mvvm

— jayars
source

btw qu'est-ce qu'une vue muli? faute de frappe?

— JensG

"Muli view" était une faute de frappe. Je voulais dire des vues différentes pour le même modèle / modèle de vue. Ma question était, dois-je remodeler / encapsuler la hiérarchie de modèle entière pour chaque vue, de sorte que chaque modèle de vue ne contienne que ce dont la vue individuelle a besoin? Ou dois-je créer une hiérarchie de modèle de vue unique contenant les propriétés de toutes les vues? Depuis que j'ai posté cette question, j'ai eu (mal) la chance de découvrir les avantages / inconvénients des deux, à la dure. Mettra à jour ce fil à l'avenir avec un diagnostic complet de mon expérience, une fois que les choses ne seront pas aussi mouvementées.

— jayars

N'oubliez pas qu'une règle de conception consiste à montrer d'abord les choses générales, puis à approfondir les détails. cela vous laissera une vue claire et si l'utilisateur va plus loin, de nouvelles vues apparaîtront. utilisez donc de petites vues avec leur modèle de vue à part. vérifier cette interface utilisateur de conception d'

— Csharls

@jsjslim J'ai frissonné quand j'ai lu "garder toutes les hiérarchies synchronisées". Je soupçonne que vous êtes allé avec le multi-vue, et je soupçonne que vous l'avez regretté (mais je me suis trompé auparavant). Pour les autres lecteurs qui peuvent avoir la même question, pouvez-vous au moins nous donner une réponse rapide (ish)?

— Guy Schalnat

@ guy-schalnat La vue multiple était une exigence. Mon problème essayait de comprendre comment construire les modèles de vue. Le projet est toujours en cours et je ne trouve pas le temps de rédiger une analyse complète. Mais en résumé: j'aurais dû ignorer la structure du modèle et me concentrer sur les vues. La complexité que j'ai rencontrée était auto-imposée: je voulais tellement mal utiliser la liaison de données de WPF que je me suis fixé. Ce que j'ai fait à la fin était bon, vieux "copier / coller / refactoriser". Le design final qui a émergé était léger (peu de répétition) et, plus important encore, fonctionnait. Rédigera une analyse complète à l'avenir.

— jayars

Réponses:

Pour répondre à la question, Oui, chaque vue doit avoir son propre modèle de vue. Mais il n'est pas nécessaire de modéliser toute la hiérarchie. Seulement ce dont la vue a besoin.

Le problème que j'ai eu avec la plupart des ressources en ligne concernant MVVM:

Dans la plupart des exemples, la vue est une cartographie presque 1: 1 du modèle. Mais dans mon scénario, où il existe différentes vues pour différentes facettes du même modèle, je me retrouve coincé entre deux choix:

Un modèle de vue monolithique utilisé par tous les autres modèles de vue

Ou un modèle de vue pour chaque vue

Mais les deux ne sont pas idéaux.

Le modèle de vue orienté modèle (MVM), bien que faible en duplication de code, est un cauchemar à maintenir

Le modèle de vue orienté vue (VVM) produit des classes hautement spécialisées pour chaque vue, mais contient des doublons.

En fin de compte, j'ai décidé qu'il était plus facile de maintenir et de coder une machine virtuelle par vue, j'ai donc opté pour l'approche VVM.

Une fois que le code fonctionne, j'ai commencé à refactoriser toutes les propriétés et opérations courantes dans leur forme finale actuelle:

Dans cette forme finale, la classe de modèle de vue commune est composée dans chaque VVM.

Bien sûr, je dois encore décider ce qui est considéré comme commun / spécialisé. Et lorsqu'une vue est ajoutée / fusionnée / supprimée, cet équilibre change.

Mais la bonne chose à ce sujet est que je suis maintenant capable de pousser les membres haut / bas du commun vers VVM et vice versa facilement.

Et une note rapide concernant la synchronisation des objets:

Avoir un modèle de vue commune s'occupe de la plupart de cela. Chaque VVM peut simplement avoir une référence au même modèle Common View.

J'ai également tendance à commencer par des méthodes de rappel simples et à évoluer vers un événement / observateur si le besoin de plusieurs auditeurs se fait sentir.

Et pour les événements vraiment complexes (c'est-à-dire les mises à jour en cascade inattendues), je passerais à l'utilisation d'un médiateur.

Je n'ai pas peur du code où un enfant a une référence arrière à son parent. Tout pour faire fonctionner le code.

Et si l'occasion de refactoriser se présentait, je la saisirais.

Les leçons que j'ai apprises:

Code laid / fonctionnel> Code beau / non fonctionnel
Il est plus facile de fusionner plusieurs petites classes que de diviser une énorme classe

— jayars
source

J'aimerais pouvoir voter deux fois. C'est l'une des explications les plus claires des options que j'ai vues.

— Clever Human

En regardant vos maquettes, je recommanderais certainement de créer une hiérarchie de ViewModels et de nombreuses petites vues. Et vous devrez probablement modéliser un peu la hiérarchie d'origine.

Pour synchroniser les choses entre les ViewModels, utilisez des événements ou ayez des propriétés entre les ViewModels. La synchronisation entre les vues et les ViewModels doit être une propriété de notification standard.

— Euphorique
source