Vantaggi di MVVM su MVC

Question

Infine ho iniziato a sviluppare Silverlight e mi sono imbattuto in MVVM. Conosco MVC e l'articolo che stavo leggendo diceva a causa di XAML, MVC non funzionava. Non avere troppa esperienza in XAML è chiaramente la ragione per cui non ho capito questo punto.

qualcuno può spiegare il motivo per cui MVC non è adatto e perché MVVM è meglio per lo sviluppo di Silverlight?

Grazie JD

Answer 1

la sua una distinzione molto sottile, che posso spiegare meglio confrontando MVC in ASP.NET e MVVM in WPF.

In ASP.NET MVC la richiesta arriva dal server web ed è gestita direttamente dal controllore. Il controller determina la vista appropriata e la popola con i modelli. Il Controller rilascia quindi queste istanze al sistema sottostante che restituisce un risultato al client. Puoi vedere che il controller è il primo e l'ultimo ad agire.

In MVVM, l'interfaccia utente (View), rivolta verso l'utilizzatore e porta direttamente input dell'utente. All'interno della vista, i comandi all'interno di ViewModel (che è il DataContext della vista) vengono attivati ​​da questa attività. Il controllo passa al ViewModel che interpreta ciò che la vista lo ha inviato e prepara i suoi modelli. Dopo che il controllo torna alla vista, si aggiorna automaticamente in base alle modifiche apportate ai modelli. Se è necessaria una nuova vista, ViewModel lo comunica con NavigationService (o con qualsiasi altro metodo di navigazione utilizzato dall'applicazione), che è l'ambito dei componenti dell'interfaccia utente di Window o Frame. Puoi vedere che ViewModel non è il primo e l'ultimo ad agire; la vista ha un ruolo molto più importante che in MVC.

L'architettura di WPF/Silverlight è il motivo per cui le cose sono fatte in questo modo. Le infrastrutture di comando, vincolanti e di navigazione non possono essere controllate/sostituite dal Controller; sono strettamente integrati con l'interfaccia utente. Quindi il Controller deve sedersi sotto la vista e assumere un ruolo più passivo.

Answer 2

Penso che l'idea sia che MVVM sia migliore adatto a XAML che MVC. Dire che MVC "non è adatto" è un po 'esagerato.

E perché MVVM è migliore? Principalmente a causa della superba data-binding e command-binding in XAML. Vedi this article.

Answer 3

MVVM è stato progettato soprattutto a causa di XAML e per rendere l'associazione dei dati ancora più semplice, è molto simile al MVP. I vantaggi principali sono il modo più semplice di manipolare l'interfaccia utente (il ViewModel o Presenter si prende cura di tale attività piuttosto che il Modello che deve attivare eventi alla vista dopo essere stata manipolata dal controller).

Le migliori due articoli che ho incontrato, che ha aiutato a capire i principi sono MVC vs MVP vs MVVM e MVVM for Tarded Folks Like Me or MVVM and What it Means to Me

Answer 4

penso che l'altro beneficio è la curva di apprendimento. Poiché la maggior parte degli sviluppatori nelle tecnologie di frontend ha utilizzato lo stile di codifica MVVM, è più facile adottare lo stesso rispetto a un modello di controller in cui devono passare ogni richiesta dalla vista al controller e comunicare con Model.

Answer 5

disaccoppiamento dei componenti

In MVC, si ha un rapporto triangolare tra i componenti. Cioè: il controllore possiede la vista e il modello. La vista si basa sulla definizione del modello. Il modello deve soddisfare i requisiti della vista.Pensa a un hub (controller) e all'architettura dei raggi (vista e modello)

In MVVM, pensa a quel triangolo che si appiattisce con ciascun componente conoscendo solo un altro nella catena. Cioè: Visualizza-> ViewModel-> Modello

Il modello non è a conoscenza di tutto lo stack. ViewModel è a conoscenza solo del modello La vista è a conoscenza solo del modello di vista: non è a conoscenza del modello.

Perché è importante?

Questo è il nucleo della domanda originale.

Lo scopo principale è un'ulteriore astrazione della tua architettura. Questo in genere porterà a un po 'più di codice, ma meno punti di contatto tra gli oggetti. Meno punti di contatto sono importanti perché questo porta a un codice più agile. Maggiore è il grado di accoppiamento/contatto della Classe A con la Classe B, maggiore sarà l'impatto di un cambiamento nella Classe A. Ridurre l'impatto del cambiamento è uno dei vantaggi chiave di una buona architettura.

Per comprendere appieno ciò, è utile riflettere su cosa rappresentano realmente i componenti. Che cos'è una vista, un controller, un ViewModel o un modello? Sono definizioni letterali o più di un concetto astratto?

Nella mia esperienza, è stato più vantaggioso per prendere in considerazione il modello da un gruppo di classi/oggetti che si occupano della costruzione e la persistenza dei dati. Non è solo un semplice oggetto vecchio con proprietà. È una classe che esegue il recupero dei dati, salva i dati, una fabbrica che costruisce oggetti semplici e vecchi. È un livello facciata che fornisce un'API chiara nei dati. Questo strato di facciata dovrebbe essere referenziato direttamente dalla vista?

A mio parere, non dovrebbe. In MVC, questa risposta è anche "no". Il controller recupera i dati dal modello. A tale riguardo, MVC e MVVM raggiungono lo stesso obiettivo. Dove le due architetture differiscono è come i dati e la vista sono collegati.

come il modello, la vista può essere un insieme di classi che in coordinamento con l'un l'altro, il rendering di una vista di presentazione. Ciò potrebbe consistere in un View Controller + View nel caso di piattaforme mobili (View Controller su iOS, Attività su Android). In molti casi, è necessario un corso per caricare un documento di visualizzazione in memoria e aggiornare le proprietà di visualizzazione. C'è molto lavoro da fare qui. In MVC, il controller diventa rapidamente una classe 'kitchen sink' - una sorta di discarica per qualsiasi cosa relativa al contesto utente corrente.

Quando si moltiplica questa dozzina di potenziali visualizzazioni all'interno dell'applicazione, si ottengono molte dipendenze tra il codice del modello back-end e il codice View front-end. Con le classi di controller di grandi dimensioni, queste dipendenze non sono immediatamente evidenti.

appiattimento le dipendenze

MVVM appiattisce le dipendenze. Questo crea attenzione. Cos'è l'attenzione? La capacità di lavorare su un singolo pezzo di funzionalità senza la distrazione di tutte le altre dipendenze. Ora puoi iniziare a scrivere test di unità su codice che in precedenza era ritenuto non testabile.

Il modello di vista funge da facciata tra la vista e il modello. Il modello di vista soddisfa le esigenze della vista: tecnicamente la vista dovrebbe possedere il modello di vista. Se la Vista richiede dati da più fonti, il Modello di vista incapsula la composizione di origini dati separate in un singolo oggetto unificato, de-normalizzato.Se la vista deve essere richiamata nel modello o in altre destinazioni, il modello di vista fornisce hook e instrada la chiamata appropriata.

Considerare come funziona una patch panel di rete. A prima vista, questo sembra ridondante - perché non collegare semplicemente la tua ethernet dal punto A al punto B. Ma con l'esperienza, capirai che un pannello di permutazione ti fornisce un pezzo chiave di astrazione che ti consente di modificare i percorsi di Point B senza influenzare il punto A. Questo è ciò che sta facendo il tuo View Model.

Ora che si dispone di un'astrazione pulita tra la vista e il modello, è necessario che la vista/il controller riguardi solo la presentazione. Ciò significa che non deve occuparsi di localizzazione o formattazione, ma riceve dati e presenta dati. Your View Model è il luogo ideale per mettere questo tipo di pre-visualizzazione dei dati di massaggio. Diciamo che è necessario filtrare i dati in base a un criterio. Ancora una volta, il modello di visualizzazione è ben informato sui dati del modello (la tua vista non lo è) ed è un ottimo posto dove inserire questo tipo di codice.

Dopo aver iniziato ad organizzare i requisiti dell'applicazione in questo modo, il codice Visualizza/Controller diventa più pulito e quando qualcosa deve essere modificato, le implicazioni sono più evidenti, il che porta a un numero inferiore di bug.

Testabilità

Una nota finale sulla verificabilità: Con appiattimento dipendenze, che rende più facile iniettare le dipendenze finte nelle vostre prove. Rende i test più facili e concisi. Il tuo modello di vista diventa qualcosa per cui puoi definire casi di test chiari.