Quali sono i problemi del pattern MVVM?

Question

Model-View-ViewModel è lo schema migliore da utilizzare in WPF? Ci sono degli aspetti negativi?

Answer 1

Ecco un breve post sul blog dello advantages and disadvantages of MVVM, direttamente dallo stesso John Gossman.

suoi principali svantaggi sono:

"Per la semplice interfaccia utente, MV-VM può essere eccessivo Nei casi più grandi, può essere difficile per la progettazione del ViewModel in anticipo al fine di ottenere la giusta quantità di generalità dei dati.. -legare per tutte le sue meraviglie è dichiarativo e più difficile eseguire il debug di cose belle e imperative in cui si impostano i punti di interruzione "

Answer 2

Sì, è un overkill per piccole applicazioni in stile mondo.

Answer 3

È un ottimo modello e, francamente, uno dei pochi pattern di UI per il WPF. Ciò che intendo è che molte persone capiscono e l'hanno adottato. Pertanto è relativamente facile ottenere aiuto e informazioni su di esso.

Il più grande svantaggio a mio parere è che aumenta il numero di classi e componenti nella vostra applicazione, perché SRP trionfi DRY in questo modello. Detto questo, penso che ne valga la pena.

Answer 4

Per creare la nostra applicazione, abbiamo iniziato con MVVM, ma dopo aver avuto molti problemi abbiamo rinunciato a MVVM per i seguenti motivi che identificheranno dove non utilizzare MVVM.

Inheritance Problema

Programmiamo in .NET, e usiamo C# e meglio siamo sicuri che vogliamo eredità. C# non supporta l'ereditarietà di più classi, quindi non possiamo avere classi astratte con la logica che saranno parzialmente riutilizzate nell'interfaccia utente e nella logica.

La maggior parte delle volte siamo confusi, come progettare Visualizza modelli in modo da poter ereditare e controllare la logica.

Se ereditiamo View, non possiamo ereditare ViewModel nello stesso momento, e se ereditiamo ViewModel, non possiamo ereditare View allo stesso tempo. Invece dobbiamo usare generici molto complicati e con l'aiuto di strumenti come Prisma e Unità che possiamo ottenere, ma non ne vale la pena.

ViewModel al ViewModel Binding

bene la maggior parte della logica di business tempo è neanche così semplice come A = B + C, UI e risposta su UI gioca un ruolo enorme. Tuttavia, possiamo associare le proprietà visive di UI alle proprietà dei dati di View Model, ma viene in dubbio come associare un modello di vista a un altro modello di vista e, se passano attraverso due collegamenti di controlli condivisi, non abbiamo idea di cosa verrà eseguito primo.

ViewModel non è semplice sostituzione di CodeBehind

Si presume che ViewModel è semplice sostituzione di file codebehind. Ma mentre facevamo la nostra app, la restrizione sull'ereditarietà ci ha insegnato che siccome WPF/Silverlight supporta UI Style che può separare completamente l'interfaccia utente con la logica, stiamo appena separando la logica di business in ViewModel.

ripetuta Codice in ViewModel

Alla fine siamo resi conto che stiamo solo scrivendo stesso modello di codice in ogni vista e ogni ViewModel, che cambia, che diventa un dolore enorme, e il mantenimento è un dolore troppo. MVVM è più adatto allo sviluppo basato su test, ma quando si tratta di scrivere componenti estensibili, non sono i migliori candidati.

---

WPF/Silverlight consente già di separare il codice e interfaccia utente molto bene, abbiamo infatti ora avete progettato gerarchia di classe molto semplice che esegue la logica di business e dare a tutti noi che abbiamo bisogno. Ora creiamo tutte le proprietà dei comandi basate su ICommand come proprietà di dipendenza delle nostre classi, che eseguiamo il binding in UserControl e in Templated Control.

ICommand in CodeBehind o Template e Stili in ResourceDictionary ci offre quasi tutti i vantaggi di ciò che possiamo ottenere su MVVM.

Answer 5

Diversi motivi hanno diversi punti di forza. Le persone tendono a confondere il modello con l'implementazione. Il modo in cui la logica aziendale è organizzata o consultata influisce su quale modello è più naturale per un'applicazione di tipo give. Quindi, anche se questa domanda riguarda WPF, potrebbe essere utile leggere tre schemi usati per impiantare lo stesso schermo tre volte in qualsiasi framework.

Di seguito è riportato un collegamento a un articolo java che confronta MVVM ("modello di presentazione") con MVP ("vista passiva") e un'implementazione ibrida MVVMP/MVC ("controllore di supervisione"). Credo che questo sia rilevante per questa domanda in quanto ha una sezione che ha un confronto tra i modelli.

Implementing event-driven GUI patterns using the ZK Java AJAX framework

Essa sottolinea la debolezza che John Gossman fa, ma va anche confrontare i due punti di forza e di debolezza, con due modelli alternativi.