Perché MVVM e quali sono i suoi principali vantaggi?

Question

Perché scegliere MVVM su MVC o MVP mentre gestiamo WPF?

Quale ulteriore vantaggio otteniamo utilizzando questo?

Edit:

Per essere onesti, oggi ho avuto un colloquio e mi è stato chiesto questa domanda. Ho risposto come INotifyPropertyChanged, ICommand, IValue Convertor .. ma non era soddisfatto. D'ora in poi ho messo su questa domanda

Grazie in anticipo

Answer 1

Ti indicherò uno video particolarmente utile di Jason Dolinger.

Provenendo da un mondo WinForms, l'implementazione di qualsiasi modello di stile MVX sembrava più complicato di quanto valesse, ma dopo aver lavorato con WPF per un paio d'anni, posso dire onestamente che non prenderei in considerazione niente di meno. L'intero paradigma è supportato immediatamente.

Prima di tutto, il vantaggio chiave sta abilitando la vera separazione tra "vista" e "modello".Ciò che significa in termini reali è che se/quando il modello ha bisogno di cambiare, può farlo senza la necessità di vedere e viceversa.

In secondo luogo, mentre il 'modello' può contenere tutti i dati che potrebbero essere necessari nella 'vista', è possibile che si desideri astrarre tali dati in modo tale che il 'modello' non supporti. Ad esempio, supponiamo che il tuo modello contenga una proprietà data. Nel modello può esistere solo come oggetto DateTime ma la tua vista potrebbe volerlo presentare in un modo completamente diverso. Senza il 'viewmodel' dovresti duplicare la proprietà nel 'modello' per supportare la vista o modificare la proprietà che potrebbe seriamente offuscare il 'modello'.

È possibile anche utilizzare un 'ViewModel' a parti aggregate del modello che esistono in classi separate/librerie per facilitare un'interfaccia più fluente per la 'vista' da affrontare. È molto improbabile che tu voglia lavorare con i dati nel tuo codice nello stesso modo in cui un utente vorrà o vorrà che i dati presentati a loro.

Inoltre, si ottiene il supporto per l'associazione automatica dei dati bidirezionali tra "view" e "viewmodel".

C'è davvero un sacco di roba extra su cui potrei cazzeggiare ma Jason dice che è lontano meglio che potrei quindi il mio consiglio è guardare il video. Dopo alcuni giorni di lavoro come questo, ti chiederai come sei riuscito a cavartela senza.

Buona fortuna.

Answer 2

cotto il supporto per ICommand e INotifyPropertyChanged sono i due più grandi benefici. L'utilizzo di MVVM semplifica il cablaggio dei comandi e inserisce i dati nell'interfaccia utente WPF. Le cose funzionano.

Answer 3

WPF ha una migliore associazione dati di qualsiasi altro framework di interfaccia utente, che MVVM sarebbe indisciplinati senza

MVVM fornisce unità testabilità e vista eccellente-agnosticismo, che lo rendono una buona cosa usare

Answer 4

Questi sono miei specifica a MVVM

1. Aumenta la "sfumabilità" delle vostre opinioni (capacità di utilizzare Expression Blend per la progettazione di visualizzazioni). Ciò consente una separazione delle responsabilità sui team che hanno la fortuna di avere un designer e un programmatore ... ognuno può lavorare indipendentemente dall'altro.
2. Logica di visualizzazione "senza look". Le viste sono agnostiche dal codice che viene eseguito dietro di esse, consentendo di riutilizzare la stessa logica di visualizzazione su più visualizzazioni o di avere una vista facilmente rinnovabile o sostituita. Separa le preoccupazioni tra "comportamento" e "stile".
3. Nessun codice duplicato per aggiornare le viste. Nel code-behind vedrai molte chiamate a "myLabel.Text = newValue" sparse ovunque. Con MVVM puoi essere certo che la vista viene aggiornata in modo appropriato semplicemente impostando la proprietà sottostante e tutti gli effetti collaterali della vista.
4. Testabilità. Dato che la tua logica è completamente indipendente dalla tua vista (senza riferimenti "myLabel.Text"), il test delle unità è facile. È possibile verificare il comportamento di un ViewModel senza coinvolgerne la vista. Ciò ha anche consentito lo sviluppo del comportamento di visualizzazione basato sui test, che è quasi impossibile utilizzare code-behind.

Gli altri due modelli sono in realtà separati in termini di preoccupazioni. È possibile utilizzare MVVM con MVP e MVC (la maggior parte dei buoni esempi là fuori fa qualche forma di questo).

In effetti, MVP (con una vista passiva, piuttosto che un supervisore di supervisione) è in realtà solo una variante di MVVM, a mio parere.

Answer 5

La capacità del codice XAML di databind e l'esistenza di trigger interromperanno i modelli MVP e MVC.

Answer 6

Personalmente vedo MVVM non come un vantaggio, ma come un obbligo per coloro che desiderano utilizzare le funzionalità di WPF.

WPF è molto molto pesantemente costruito con l'associazione dati al centro, per consentire la separazione dell'interfaccia utente dal modello. Ma il modo vincolante tecnicamente fatto in WPF dati è un po 'speciale, come è legato alle classi come:

• DependencyProperty
• INotifyPropertyChanged
• ObservableCollection

A causa di questo proprio non posso scrivi davvero un modello nel modo che desideri utilizzando la tecnologia .NET standard. Ad esempio, WPF TreeView è quasi impossibile da usare senza utilizzare associazione dati e modelli. Ad esempio, non puoi popolarlo semplicemente come faresti da un modello generico in Winforms. È deve essere associato a un modello gerarchico utilizzando ObservableCollection per rappresentare i figli di un nodo.

Quindi diciamo che V rappresenta il codice XAML ed è controparte code-behind (quindi è legato a WPF come tecnologia), e diciamo che M rappresenta il modello (quindi non è legato alla tecnologia UI WPF in ogni caso).

Beh, non dovrete mai questo lavoro correttamente in WPF con solo questi V & M.

È necessario aggiungere qualcosa tra i due. Qualcosa che sia compatibile con WPF e capisca il tuo modello. Qualcosa che parla DependencyProperty, ObservableCollection e INotifyPropertyChanged. Questo è ciò che si chiama VM.

Come nota a margine, un'alternativa a MVVM consiste nel creare una combinazione V & M (senza VM) con M che sia compatibile con WPF ma con una ragionevole indipendenza dell'interfaccia utente. Storicamente, ObservableCollection era nell'assembly WindowsBase.dll (fornito con WPF), quindi sembrava davvero strano associare un modello generico a qualcosa di legato a una tecnologia dell'interfaccia utente. È stato spostato di nuovo in System.dll da allora. Anche in questo caso, a volte è difficile mantenere un modello VM puro senza ottimizzare la M in modo specifico per WPF ...