2010-02-17 9 views
6

In pattern MVP, un Presenter ha un'interfaccia di visualizzazione in modo che il presentatore possa chiamare iview.DoSomething(). Che cosa succede nel pattern MVVM?Un ViewModel può parlare con View in MVVM pattern?

Secondo il diagramma UML di John Gossman http://blogs.msdn.com/johngossman/archive/2006/04/13/576163.aspx, ViewModel non ha un'interfaccia di visualizzazione. Quindi, sembra che ViewModel e View debbano essere comunicati solo tramite Binding. (o utilizzare proprietà associate o comportamento di fusione o ecc.).

Cosa ne pensate?

+0

Ciao Skaffman, grazie .. Che cosa hai modificato? :) –

+0

Ha aggiunto il tag design-patterns. Controlla la cronologia delle modifiche facendo clic sul testo "modificato". – stiank81

+0

grazie ... fantastico ... non ho visto quel testo "modificato" .. Vedo solo "modifica | rollback | elimina | flag". comunque, grazie per aver aggiunto un altro tag per il mio post ... –

risposta

5

Sono d'accordo con John Gossman. Il modo in cui ViewModel "parla" con la vista avviene solo tramite binding. In effetti, il ViewModel non dovrebbe preoccuparsi della vista. Dovrebbe semplicemente rendere i dati disponibili attraverso le proprietà, e spetta alla vista decidere cosa si associerà dinamicamente in ViewModels. Se ViewModel vuole dire alla vista qualcosa che dovrebbe accadere implicitamente tramite Bindings.

Una domanda simile è stata presentata un'ora fa - here.

+0

Grazie mille. Sono d'accordo anche con quello. quando stavo scrivendo questo post http: // michaelsync.net/2010/02/03/rules-of-mvvm, alcuni hanno detto che va bene avere l'interfaccia di visualizzazione in ViewModel. Ho detto loro che sarà uno schema MVP. ovviamente, possiamo mescolare i pattern ma penso che avere un'interfaccia di View in VM violi il pattern MVVM .. Grazie per la tua risposta .. Lo apprezzo davvero. –

+0

Sembra che tu sia sulla strada giusta. Felice di essere di aiuto. Controllerà il tuo post sul blog! :-) – stiank81

+0

Grazie. per favore fatemi sapere se avete qualche commento o suggerimento per quel post .. :) –

1

L'intero scopo di MVVM è di ridurre notevolmente la quantità di codice nella classe code-behind del modulo WPF o del controllo utente. L'idea è che qualsiasi cosa possa essere gestita dalla vista in MVC/MVP classico può essere trasferita alla VM utilizzando una combinazione di associazione dati e/o comandi. Nel mio uso generale di MVVM sono riuscito a rimuovere completamente tutto il code-behind nei miei moduli/controlli utente e la VM non ha alcuna conoscenza diretta della vista che sta controllando. Se hai una situazione che non può essere gestita da un'associazione dati o da un comando, ti preghiamo di approfondire la tua domanda iniziale e io (o uno dei tanti MVVM'er più talentuosi qui presenti) cercheremo di indicarti la giusta direzione .

+0

Grazie. La domanda è ~ Pensi che avere un'interfaccia di View in ViewModel violi il pattern MVVM? Esempio: IPersonView, PersonView e PersonViewModel .. e PersonViewModel hanno IPersonView ... –

+0

Ciao scusa il commento e ci vediamo che hai accettato Stian rispondi ma per completezza ecco la mia risposta. Penso che violi il pattern MVVM (a mio modo di vedere) e come ora accennato usando l'associazione dei dati attraverso le proprietà esposte è il modo di aggiornare la vista. Sono contento che tu abbia ricevuto una risposta :) –

+0

Grazie, amico ... In realtà, anche il tuo post mi ha risposto, ma il problema qui è che non posso contrassegnare più di un post come risposta. Poiché non esiste una regola standard e nessun proprietario/creatore per il pattern MVVM, dobbiamo chiedere a tutti se siamo d'accordo o no. :) Ecco perché sto facendo la domanda su MVVM in diverse comunità e scrivi informazioni riassuntive in uno dei miei post .. –

1

In genere, gli eventi su INotifyProperty sono cambiati, se non altro.

+0

Mi dispiace. Non ti ho preso .. Stai parlando di avere un'interfaccia di View in VM? –

+1

Supponendo che si stia parlando di C#, gli eventi esposti nell'interfaccia INotifyPropertyChanged vengono generalmente ascoltati (tramite associazione dati) dalla vista. L'associazione dei dati non è davvero magica: sta semplicemente collegando i gestori agli eventi su INotifyPropertyChanged e INotifyCollectionChanged. Ma sì, direi che in genere il VM vuol parlare con la vista, per informarla delle modifiche dei dati. Ha un'idea di un * * astratto vista, però, e non una particolare implementazione - la comunicazione dovrebbe essere limitato a "questo è cambiato" e non "in modo da cambiare questo controllo" – kyoryu

+0

Sì .. Quindi, "questo cambiato" Limitazione = Dati Binding, giusto? :) –

1

Può un ViewModel parlare con Visualizza nel modello MVVM?

Sì, ma in un modo disaccoppiato. È consentito introdurre un'interfaccia IView per la comunicazione.

Il pattern MVVM sta per spostare la logica dalla vista nel ViewModel. In questo modo siamo in grado di testare questa logica unitamente.

+0

Ho guardato WAF molto tempo fa. Ho visto che il creatore di WAF imposta la password nel codice dietro in Demo. Non sono sicuro del perché lo faccia. >> Sì, ma in modo disaccoppiato. Quindi, quali sarebbero le differenze tra il pattern MVP e MVVM? Possiamo anche spostare la logica in Presenter in MVP. Pensi che va bene per impostare iview.DoSomething da ViewModel? –

+0

Dal punto di vista del disaccoppiamento e della testabilità è definitivamente permesso chiamare IView.DoSomething dal ViewModel. Se si utilizza Binding, si definisce quindi una proprietà di ViewModel. Quindi la vista è a conoscenza della proprietà di ViewModel. È solo che Binding usa Reflection (non è sicuro) ma l'accoppiamento è lo stesso. – jbe

+0

per il disaccoppiamento e la testabilità, non è nemmeno necessario utilizzare il pattern MVVM. MVC o MVP o ecc sono testabili pure. Ho ancora due domande. 1) Se hai detto che va bene avere un'interfaccia di View in ViewModel. Puoi dirmi le differenze tra MVP o MVVM? Puoi anche leggere la mia discussione con Glenn in questo link http://groups.google.com/group/wpf-disciples/browse_thread/thread/7588c66f21fb82af. 2) Pensi che è bene fare ((ViewModel) this.DataContext) .DoThat() in troppo? –

Problemi correlati