È considerato una cattiva pratica che gli oggetti ViewModel mantengano il Dispatcher?

Question

La mia applicazione WPF è strutturata utilizzando il pattern MVVM. ViewModels comunicherà in modo asincrono con un server e quando i dati richiesti verranno restituiti, verrà richiamato un richiamo nel ViewModel e farà qualcosa con questi dati. Questo verrà eseguito su un thread che non è il thread dell'interfaccia utente. A volte questi callback implicano lavoro che deve essere fatto sul thread dell'interfaccia utente, quindi ho bisogno del Dispatcher. Questo potrebbe essere cose come:

• Aggiunta di dati a un ObservableCollection
• comandi trigger Prism che impostare qualcosa da visualizzare nella GUI
• Creazione di oggetti WPF di qualche tipo.

Cerco di evitare quest'ultimo, ma i due primi punti qui ritengo siano cose ragionevoli da fare per ViewModels. Così; va bene avere ViewModels che mantiene il Dispatcher in grado di richiamare i comandi per il thread dell'interfaccia utente? O è considerata una cattiva pratica? E perché?

Answer 1

Da ObservableCollection deve essere aggiornati sulla filettatura appartenenza (assumendo un'applicazione GUI), e ObservableCollections dovrebbe essere parte del ViewModel, allora c'è un caso chiaro per il ViewModel avere un Dispatcher.

Non riesco a vederlo essere parte del Modello.

Answer 2

Sono d'accordo con kyoryu e vorrei notare che crea solo una dipendenza dal lobrary di ServiceModel (che avete già) e non dalla Vista stessa, quindi c'è ben poco da obiettare contro questa costruzione.

Stavo provando alcune cose con WPF, una semplice VM e thread ieri e sono giunto alla conclusione che avevo assolutamente bisogno di passare il Dispatcher alla VM.

vedere anche Using WPF UI thread should always ensure STA apartment mode, right?

Answer 3

Idealmente, un ViewModel dovrebbe essere totalmente indipendente dalla tecnologia di interfaccia utente utilizzata. Dovremmo teoricamente essere in grado di riutilizzarlo per Windows Form (se magnaccia le Windows Form controlla un po 'per supportare meglio vincolante), per pagine Web (mi immagino qualche tipo di meccanismo di speciale qui che la compilazione il ViewModel anche in Javascript) e per eventuali tecnologie future. Non tutte queste tecnologie utilizzeranno il modello Dispatcher.

Detto questo, lo considero un compromesso pragmatico per includere lo Dispatcher nello ViewModel al giorno d'oggi. Nella mia classe di base ViewModel, io controllare la corrente Dispatcher:

protected override void OnPropertyChanged(object sender, PropertyChangedEventArgs e) 
    { 
     if (Deployment.Current.Dispatcher == null || Deployment.Current.Dispatcher.CheckAccess()) 
     { 
      base.OnPropertyChanged(sender, e); 
     } 
     else 
     { 
      Deployment.Current.Dispatcher.BeginInvoke(() => base.OnPropertyChanged(sender, e)); 
     } 
    } 

Ho ancora la dipendenza System.Windows naturalmente, ma vabbè. : ->

Answer 4

Si consiglia di utilizzare invece AsyncOperation.