In MVVM, ViewModel o View dovrebbero essere responsabili della creazione di nuove visualizzazioni?

11

Nella mia applicazione WPF, voglio creare una nuova vista. Dove dovrei farlo - in ViewModel o Model ?

L'applicazione è uno strumento simile a una finestra (molto semplice per ora) con un solo pulsante "invia". Nel caso in cui sia selezionata una delle caselle di controllo, dovrebbe apparire una nuova finestra che utilizza lo stesso ViewModel per chiedere all'utente ulteriori dettagli. Ai fini di questa domanda, consideriamo solo il nuovo approccio della finestra senza considerare altri approcci come il pannello mostrato / nascosto.

Idealmente, in View non dovrebbe esserci alcun codice. Inoltre, poiché View non ha alcuna logica in essa, la VM dovrebbe inizialmente verificare se è necessaria la creazione di una nuova visualizzazione e, quando lo è, rimandare questa responsabilità a View, portando a un gonfiamento del codice.

D'altra parte, la creazione di una nuova vista in ViewModel viola il principio secondo cui ViewModel non dovrebbe sapere nulla di View.

Quindi, è meglio creare nuove viste in View o ViewModel?

c# design wpf mvvm

— Mac70
fonte

1

Non capisco davvero la tua domanda. Che cosa significa "In View o ViewModel"? ViewModels non crea viste e certamente le viste non creano se stesse.

— Robert Harvey,

1

Voglio dire quale di questi livelli dovrebbe essere responsabile della creazione di nuove viste - segnale di fare che deve provenire da qualche parte quando si verifica l'azione. Ho escluso completamente il modello da questa domanda, perché non dovrebbe sapere nulla del frontend.

— Mac70,

Forse non capisco correttamente la tua domanda, entrambi non dovrebbero interferire con la tua visione. Se si desidera creare una nuova vista nel proprio viewModel, c'è qualche motivo per cui non si utilizzano i frame in xaml per modificare il contenuto di Window con un'associazione al viewModel corrente?

— Siobhan,

8

Uso l'iniezione di dipendenza e un'iniezione IViewFactorynel modello di visualizzazione per rispettare entrambi i vincoli.

Un ProductViewModel(per esempio) chiama this.viewFactory.Show("Details", this)per aprirsi ProductDetailsViewcon se stesso come ProductViewModel. Potrebbe anche aprire una vista basata su un altro modello di vista con this.viewFactory.Show<ClientViewModel>().

L'implementazione (in realtà ce ne sono diverse per WinForms, Windows Wpf semplice, una shell Wpf con schede, ...) si basa su una StructureMapconvenzione. Le viste designano il loro modello di vista tramite IView<ProductViewModel>un'interfaccia.

Quindi il modello della vista non conosce nulla della vista tranne il suo ruolo (vista predefinita, vista dettagli, ...) e la vista non contiene alcun codice per creare un'altra vista. Inoltre, i modelli di vista si trovano in un assembly separato che non fa riferimento a nessun assembly Wpf.

— Philippe
fonte

7

Risposta teorica

Se hai un ViewModel, le azioni che hanno effetti cosmetici (ad esempio evidenziare un oggetto al passaggio del mouse) sono il lavoro di View, mentre le azioni che hanno effetti "reali" (ad esempio la generazione di una nuova finestra) sono il lavoro di ViewModel.

Pertanto, la creazione di una nuova finestra è un lavoro per ViewModel. Tuttavia, né la vista né i ViewModeldovrebbero sapere esattamente come creare una finestra, questo non fa parte delle loro responsabilità e appartiene a una classe diversa.

Si potrebbe sostenere che la creazione di una nuova finestra è un lavoro per View. Anche se non sarei d'accordo, in questo dibattito c'è poco valore, perché in pratica non è la fine del mondo se inserisci quel codice in View, e inoltre non è molto lavoro spostarlo ViewModelin un momento successivo . La parte importante è che la logica per la creazione di una nuova finestra è contenuta in una classe indipendente, di solito un qualche tipo di WindowFactory. Il punto di MVVM, MVP, MVC, ecc. È che hai classi con poche e ben definite responsabilità. Ecco perché non si aggiunge ulteriori responsabilità al View, ViewModelo Modelse non è necessario.

In nessun caso la creazione della finestra appartiene alla Model, perché Modelnon è nemmeno consapevole che esiste qualcosa come una GUI.

Risposta pratica

Si tratta di uno "strumento simile a una finestra con un solo pulsante" invia " . Quindi ecco una spina spudorata per una mia risposta correlata: Perché usare MVVM?

Per riassumere ciò che dice questa risposta: Mantieni la semplicità. Oh, e tieni a mente la risposta teorica sopra da implementare una volta che la tua finestra a pulsante singolo inizia a diventare più complessa.

— Peter
fonte