MVVM - finestre secondarie e contesti dati

Penso che dipenda. Sul progetto al quale sto lavorando attualmente, abbiamo utilizzato entrambi gli approcci. Suppongo che dipenda dal modo in cui le funzionalità della finestra figlia sono correlate al genitore. Se la nuova finestra è per lo più supplementare, come una finestra di dialogo di prompt o secondario, ho semplicemente usato il contesto dei dati del genitore perché i dati forniti attraverso quella finestra di dialogo erano ancora molto rilevanti per la funzionalità del genitore. D'altra parte, se la nuova finestra è di per sé una caratteristica significativa, potrebbe essere più appropriato utilizzare un nuovo contesto di dati che riporta al genitore (se applicabile). Pensa in questo modo, quando si progetta una classe, quando è opportuno suddividere la funzionalità in un'altra classe? Non si vuole necessariamente un modello di visualizzazione ingombrante con una serie di funzionalità indipendenti raggruppate insieme.
Sfortunatamente, questa è diventata una risposta piuttosto confusa che dipende dal tuo miglior giudizio.

La regola che userei è un ViewModel per View. Se è qualcosa di molto generico, piuttosto che un Controllo piuttosto che una Vista specifica. In quel caso userebbe DataContext di parent View. Gli avvisi MessageBox possono essere visualizzati anche utilizzando una sorta di classe di servizio che si inserirà in ViewModels. ViewModels può anche avere altri ViewModels annidati in essi, ad esempio quando si utilizzano controlli di tipo Grid.

Mi sembra che ogni vista figlia debba avere il proprio modello di vista. Dico questo perché se tu fossi togliere la vista figlio dalla vista genitore avresti i dati ridondanti (che erano intesi per la vista figlio) seduti nel modello di visualizzazione genitore. Mi sembra che solo per questo motivo sarebbe più sensato avere un modello di vista per ciascuno.