Aiuto con MVVM complesso (più viste)

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 è quasi la mappatura 1 a 1 del modello. Ma nel mio scenario, dove ci sono diversi punti di vista per le diverse sfaccettature dello stesso modello, mi trovo bloccato tra due scelte:

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

Ounmodellodivistaperognivista

Maentrambinonsonoideali.

IlModelViewMVM(Model-orientedViewModel),mentreilbassonelladuplicazionedelcodice,èunincubodamantenere

IlViewModelViewViewer(VVM)produceclassialtamentespecializzateperognivista,macontieneduplicati.

Allafine,hodecisocheavereunaVMperViewèpiùfaciledamantenereeprogrammare,quindisonoandatoconl'approccioVVM.

Unavoltacheilcodicefunziona,hoiniziatoarefactoringtutteleproprietàeleoperazionicomuninellasuaformaattualeedefinitiva:

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

Naturalmente, 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 posso spingere su / giù i membri da common a VVM e viceversa facilmente.

E una breve nota sulla conservazione degli oggetti durante la sincronizzazione:

Avere un Common View Model si prende cura di gran 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, e evolvendo verso eventi / osservatori se sorge la necessità di più ascoltatori.

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

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

E se sorgesse l'opportunità di un refactoring, lo prenderei.

Le lezioni che ho imparato:

1. Codice brutto / funzionante > Codice bello / non funzionante
2. È più facile unire più classi piccole, piuttosto che suddividere una grande classe

Osservando i tuoi prototipi, ti consiglio vivamente di creare una gerarchia di ViewModels e molte piccole viste. E molto probabilmente dovrai modellare un bel po 'della gerarchia originale.

Per mantenere le cose in sincronia tra ViewModels, utilizzare entrambi gli eventi o avere proprietà tra loro tra ViewModels. La sincronizzazione tra Views e ViewModels dovrebbe essere la notifica standard delle proprietà.