Il posto migliore per aprire una nuova finestra in Vista modello ViewModel

Question

Ho un'applicazione MVVM. In uno dei ViewModels è il 'FindFilesCommand' che popola una ObservableCollection. Quindi implemento un 'RemoveFilesCommand' nello stesso ViewModel. Questo comando fa apparire una finestra per ottenere un po 'più di input da parte dell'utente.

Dove/qual è il modo migliore per farlo mantenendo il paradigma MVVM? In qualche modo facendo:

new WhateverWindow().Show()

nel ViewModel sembra sbagliato.

Cheers,

Steve

Answer 1

Personalmente, considero questo scenario come uno in cui il modello di visualizzazione finestra principale desidera eseguire il prospetto di un compito per l'utente finale.

Dovrebbe essere responsabile della creazione dell'attività e dell'inizializzazione. La vista dovrebbe essere responsabile della creazione e della visualizzazione della finestra secondaria e dell'utilizzo dell'attività come modello di visualizzazione della finestra appena istanziata.

L'attività può essere annullata o confermata. Alza una notifica quando è completata.

La finestra utilizza la notifica per chiudersi. Il modello di visualizzazione genitore utilizza la notifica per eseguire un lavoro aggiuntivo una volta che l'attività ha eseguito il commit se è in corso un'operazione di follow-up.

Credo che questo sia il più vicino alla cosa naturale/intuitiva che le persone fanno con il loro approccio code-behind, ma reinterpretato per dividere le preoccupazioni indipendenti dall'interfaccia utente in un modello di vista, senza introdurre un ulteriore sovraccarico concettuale come servizi ecc.

Ho un'implementazione di questo per Silverlight. Vedi http://www.nikhilk.net/ViewModel-Dialogs-Task-Pattern.aspx per maggiori dettagli ... Mi piacerebbe sentire commenti/ulteriori suggerimenti su questo.

Answer 2

per i dialoghi di questo tipo. Lo definisco come una classe nidificata di FindFilesCommand. Se la finestra di dialogo di base viene usata tra molti comandi, la definisco in un modulo accessibile a quei comandi e ha il comando di configurare la finestra di dialogo di conseguenza.

Gli oggetti comando sono sufficienti per mostrare il modo in cui il dialogo interagisce con il resto del software. Nel mio software gli oggetti Command risiedono nelle loro librerie, quindi le finestre di dialogo sono nascoste dal resto del sistema.

Per fare qualsiasi cosa, l'entusiasmo è eccessivo secondo me. Inoltre, cerca di mantenerlo ai massimi livelli, spesso implicando la creazione di molte interfacce e metodi di registrazione aggiuntivi. È un sacco di codice per poco guadagno.

Come ogni struttura, la devozione servile ti condurrà in qualche strano vicolo. Hai bisogno di usare il giudizio per vedere se ci sono altre tecniche da usare quando ottieni un cattivo odore di codice. Anche a mio parere, le finestre di dialogo dovrebbero essere strettamente vincolate e definite accanto al comando che le usa. In questo modo, cinque anni dopo, posso tornare a quella sezione del codice e vedere tutto ciò che il comando ha a che fare.

Sempre nelle poche istanze in cui una finestra di dialogo è utile per più comandi, la definisco in un modulo comune a tutti. Tuttavia nel mio software forse 1 su 20 dialoghi è come questo. L'eccezione principale è la finestra di dialogo di apertura/salvataggio del file. Se una finestra di dialogo viene utilizzata da dozzine di comandi, passerò all'intero percorso di definizione di un'interfaccia, creando un modulo per implementare quell'interfaccia e registrare tale modulo.

Se la localizzazione per l'uso internazionale è importante per la tua applicazione, dovrai assicurarti di avere un account con questo schema poiché tutti i moduli non sono in un modulo.

Answer 3

Ho avuto questo problema anche con MVVM. Il mio primo pensiero è cercare di trovare un modo per non usare il dialogo. Usando WPF è molto più facile trovare un modo più semplice di fare le cose che con una finestra di dialogo.

Quando ciò non è possibile, l'opzione migliore sembra essere che il ViewModel chiama una classe condivisa per ottenere le informazioni dall'utente. ViewModel dovrebbe essere completamente inconsapevole della visualizzazione di una finestra di dialogo.

Quindi, come un semplice esempio, se si desiderava che l'utente confermasse l'eliminazione, ViewModel poteva chiamare DialogHelper.ConfirmDeletion(), che restituirebbe un valore booleano se l'utente ha risposto sì o no. La visualizzazione effettiva della finestra di dialogo verrebbe eseguita nella classe Helper.

Per finestre di dialogo più avanzate, restituendo molti dati, il metodo di supporto deve restituire un oggetto con tutte le informazioni dalla finestra di dialogo in esso.

Sono d'accordo che non è la soluzione più fluida con il resto di MVVM, ma non ho ancora trovato esempi migliori.

Answer 4

Devo dire che i servizi sono la strada da percorrere qui.

L'interfaccia di servizio fornisce un modo per restituire i dati. Quindi l'effettiva implementazione di quel servizio può mostrare una finestra di dialogo o qualsiasi altra cosa per ottenere le informazioni necessarie nell'interfaccia.

In questo modo è possibile testare l'interfaccia di servizio nei test e il ViewModel non è il più saggio. Per quanto riguarda ViewModel, ha richiesto un servizio per alcune informazioni e ha ricevuto ciò di cui aveva bisogno.

Answer 5

In realtà esempio Southridge di Jaime Rodriguez e Karl Shifflet, che stanno creando la finestra nel ViewModel, più precisamente nella parte eseguire un comando associato:

protected void OnShowDetails (object param) 
    { 
     // DetailsWindow window = new DetailsWindow(); 
     ListingDetailsWindow window = new ListingDetailsWindow(); 
     window.DataContext = new ListingDetailsViewModel (param as Listing, this.CurrentProfile) ; 
     ViewManager.Current.ShowWindow(window, true); 
    } 

Ecco il link: http://blogs.msdn.com/jaimer/archive/2009/02/10/m-v-vm-training-day-sample-application-and-decks.aspx

Immagino che questo non sia un grosso problema. Dopo tutto, il Viewmodel funge da "colla" tra la vista e il livello aziendale/livello dati, quindi è normale essere accoppiati alla vista (UI) ...

Answer 6

Onyx (http://www.codeplex.com/wpfonyx) fornirà un equo bella soluzione per questo. Per fare un esempio, guardate il servizio ICommonDialogProvider, che può essere utilizzato da un ViewModel come questo:

ICommonFileDialogProvider provider = this.View.GetService<ICommonDialogProvider>(); 
IOpenFileDialog openDialog = provider.CreateOpenFileDialog(); 
// configure the IOpenFileDialog here... removed for brevity 
openDialog.ShowDialog(); 

Questo è molto simile ad usare l'OpenFileDialog cemento, ma è pienamente verificabile. La quantità di disaccoppiamento di cui hai veramente bisogno sarebbe un dettaglio di implementazione per te. Ad esempio, nel tuo caso potresti volere un servizio che nasconda del tutto il fatto che stai usando una finestra di dialogo. Qualcosa sulla falsariga di:

public interface IRemoveFiles 
{ 
    string[] GetFilesToRemove(); 
} 

IRemoveFiles removeFiles = this.View.GetService<IRemoveFiles>(); 
string[] files = removeFiles.GetFilesToRemove(); 

È quindi necessario garantire la vista ha un'implementazione per il servizio IRemoveFiles, per i quali vi sono diversi opzioni a vostra disposizione.

Onyx non è ancora pronto per il rilascio, ma il codice è completamente funzionante e utilizzabile come punto di riferimento. Spero di rilasciare stabilizzare l'interfaccia V1 molto presto, e verrà rilasciato non appena avremo documentazione e campioni decenti.

Answer 7

Quello che stiamo facendo è somethng così, ciò che è descritto qui: http://www.codeproject.com/KB/WPF/DialogBehavior.aspx?msg=3439968#xx3439968xx

Il ViewModel ha una proprietà che si chiama ConfirmDeletionViewModel. Non appena imposto la proprietà, il comportamento apre la finestra di dialogo (modale o meno) e utilizza ConfirmDeletionViewModel. Inoltre sto passando un delegato che viene eseguito quando l'utente vuole chiudere la finestra di dialogo. Questo è fondamentalmente un delegato che imposta la proprietà ConfirmDeletionViewModel su null.