Aiuto con MVVM complesso (più viste)

Ho bisogno di aiuto per creare modelli di visualizzazione per il seguente scenario:

Dati gerarchici profondi
Visualizzazioni multiple per lo stesso set di dati
Ogni vista è una singola vista che cambia dinamicamente, in base alla selezione attiva
A seconda del valore di una proprietà, visualizzare diversi tipi di schede in un controllo scheda

inserisci qui la descrizione dell'immagine

Le mie domande:

Devo creare una rappresentazione del modello di vista per ciascuna vista (VM1, VM2, ecc.)?

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?

Ecco un esempio di una vista singola

Figura 1: viste multiple aggiornate in base alla stanza attiva. Avviso Tab control

inserisci qui la descrizione dell'immagine

Figura 2: diversa stanza attiva. Visualizzazioni multiple aggiornate. Gli elementi di controllo della scheda sono stati modificati in base alla proprietà dell'oggetto.

inserisci qui la descrizione dell'immagine

Figura 3: diverso tipo di selezione. La vista intera cambia

inserisci qui la descrizione dell'immagine

wpf mvvm

— jayars
fonte

tra cosa è una vista muli? errore di battitura?

— JensG,

"Muli view" era un errore di battitura. Intendevo visioni diverse per lo stesso modello / modello di visualizzazione. La mia domanda era: dovrei rimodellare / avvolgere l'intera gerarchia del modello per ogni vista, quindi ogni modello di vista contiene solo ciò di cui ha bisogno la vista individuale? O dovrei creare una gerarchia di modelli a vista singola che contiene proprietà da tutte le viste? Da quando ho pubblicato questa domanda, sono stato (non) abbastanza fortunato da scoprire i pro / contro dei due, nel modo più duro. Aggiornerò questo thread in futuro con una diagnosi completa della mia esperienza, una volta che le cose non saranno così frenetiche.

— jayars,

Ricorda che una regola di progettazione consiste nel mostrare prima le cose generali, quindi approfondire i dettagli. ti lascerà con una vista chiara e se l'utente approfondisce, appariranno nuove viste. quindi usa le viste piccole con il loro modello di vista a parte. consulta questo articolo design interfaccia utente

— Csharls

@jsjslim Rabbrividii quando lessi "mantieni sincronizzate tutte le gerarchie". Ho il sospetto che tu abbia optato per la visualizzazione multipla e sospetto che te ne sia pentito (ma ho sbagliato prima). Per il bene di altri lettori che potrebbero avere la stessa domanda, puoi almeno darci una risposta rapida (ish)?

— Guy Schalnat,

@ guy-schalnat Il multi-view era un requisito. Il mio problema era cercare di capire come costruire i modelli di vista. Il progetto è ancora in corso e non riesco a trovare il tempo per scrivere un'analisi completa. In sintesi: avrei dovuto ignorare la struttura del modello e concentrarmi sulle viste. La complessità che ho incontrato è stata autoimposta: volevo usare l'associazione dei dati di WPF così male, mi sono aggiustata. Quello che ho fatto alla fine è stato buono, vecchio "copia / incolla / refactor". Il design finale che è emerso è stato leggero (poca ripetizione) e, soprattutto, ha funzionato. Scriverà un'analisi completa in futuro.

— jayars,

Risposte:

Per rispondere alla domanda, Sì, ogni vista dovrebbe avere il proprio modello di vista. Ma non è necessario modellare l'intera gerarchia. Solo ciò di cui ha bisogno la vista.

Il problema che ho riscontrato con la maggior parte delle risorse online riguardanti MVVM:

Nella maggior parte degli esempi, la vista è una mappatura quasi 1 a 1 del modello. Ma nel mio scenario, in cui ci sono viste diverse per diverse sfaccettature dello stesso Modello, mi trovo bloccato tra due scelte:

Un modello di vista monolitico utilizzato da tutti gli altri modelli di vista

O un modello di vista per ogni vista

Ma entrambi non sono l'ideale.

Il modello di visualizzazione orientato al modello (MVM), sebbene a basso livello di duplicazione del codice, è un incubo da mantenere

Il modello di vista orientato alla vista (VVM) produce classi altamente specializzate per ogni vista, ma contiene duplicati.

Alla fine, ho deciso che avere una VM per View è più facile da gestire e codificare, quindi ho scelto l'approccio VVM.

Una volta che il codice funziona, ho iniziato a refactoring tutte le proprietà e le operazioni comuni nella sua forma attuale e finale:

In questa forma finale, la classe del modello di vista comune è composta in ogni VVM.

Certo, devo ancora decidere cosa è considerato comune / specializzato. E quando una vista viene aggiunta / unita / eliminata, questo equilibrio cambia.

Ma la cosa bella di questo è che ora sono in grado di spingere su / giù i membri dal comune a VVM e viceversa facilmente.

E una breve nota relativa alla sincronizzazione degli oggetti:

Avere un modello di vista comune si occupa della maggior parte di questo. Ogni VVM può semplicemente avere un riferimento allo stesso modello di visualizzazione comune.

Tendo anche a iniziare con semplici metodi di callback, evolvendo in evento / osservatore se dovesse sorgere la necessità di più ascoltatori.

E per eventi davvero complessi (ad es. Aggiornamenti inaspettati a cascata), passerei all'utilizzo di un mediatore.

Non esito dal codice in cui un bambino ha un riferimento posteriore al suo genitore. Qualsiasi cosa per far funzionare il codice.

E se si presentasse l'opportunità di refactoring, la prenderei.

Le lezioni che ho imparato:

Codice brutto / funzionante> Codice bello / non funzionante
È più facile unire più classi piccole piuttosto che suddividere una classe enorme

— jayars
fonte

Vorrei poter votare questo due volte. Questa è una delle spiegazioni più chiare delle opzioni che ho visto.

— Clever Human

Guardando i tuoi modelli, consiglierei sicuramente di creare una gerarchia di ViewModels e molte piccole viste. E molto probabilmente dovrai modellare un po 'della gerarchia originale.

Per mantenere le cose in sincronia tra ViewModels, utilizzare uno degli eventi o disporre di proprietà reciproche tra ViewModels. La sincronizzazione tra Views e ViewModels dovrebbe essere proprietà di notifica standard.

— Euforico
fonte