Qual è la differenza tra MVC e MVVM? [chiuso]

C'è una differenza tra il modello "Controller vista modello standard" e il modello Modello / Visualizza / Visualizza modello di Microsoft?

MVC / MVVM non è una scelta / o .

I due modelli emergono, in modi diversi, sia nello sviluppo ASP.Net che Silverlight / WPF.

Per ASP.Net, MVVM viene utilizzato per associare i dati bidirezionali all'interno delle viste. Di solito si tratta di un'implementazione lato client (ad es. Utilizzando Knockout.js). MVC d'altra parte è un modo per separare le preoccupazioni sul lato server .

Per Silverlight e WPF, il modello MVVM è più completo e può sembrare che sostituisca MVC (o altri schemi di organizzazione del software in responsabilità separate). Un'ipotesi, che spesso è venuto fuori da questo modello, era che il ViewModelsemplicemente sostituito il controllore in MVC(come se si può solo sostituire VMper Cla sigla e tutto sarebbe stato perdonato) ...

Il ViewModel non non necessariamente sostituisce la necessità di controller separati.

Il problema è: che per essere verificabili in modo indipendente * e specialmente riutilizzabili quando necessario, un modello di vista non ha idea di quale vista lo stia visualizzando, ma soprattutto non ha idea da dove provengano i suoi dati .

* Nota: in pratica i controller rimuovono la maggior parte della logica, dal ViewModel, che richiede test unitari. La VM diventa quindi un contenitore stupido che richiede pochi, se del caso, test. Questa è una buona cosa poiché la VM è solo un ponte, tra il progettista e il programmatore, quindi dovrebbe essere semplice.

Anche in MVVM, i controller in genere contengono tutta la logica di elaborazione e decidono quali dati visualizzare in quali viste utilizzando quali modelli di vista.

Da quello che abbiamo visto finora il principale vantaggio del modello ViewModel per rimuovere il codice da XAML code-behind per rendere la modifica XAML un'attività più indipendente . Creiamo ancora controller, quando e quando necessario, per controllare (non è previsto il gioco di parole) la logica generale delle nostre applicazioni.

Le linee guida di base MVCVM che seguiamo sono:

• Le viste mostrano una certa forma di dati . Non hanno idea da dove provengano i dati.
• I ViewModel contengono una determinata forma di dati e comandi , non sanno da dove provengano i dati o il codice o come vengano visualizzati.
• I modelli contengono i dati effettivi (vari contesti, archivi o altri metodi)
• I controller ascoltano e pubblicano eventi. I controller forniscono la logica che controlla quali dati vengono visualizzati e dove. I controller forniscono il codice comando a ViewModel in modo che ViewModel sia effettivamente riutilizzabile.

Abbiamo anche notato che il framework code-gen di Sculpture implementa MVVM e uno schema simile a Prism AND e fa inoltre ampio uso dei controller per separare tutta la logica del caso d'uso.

Non dare per scontato che i controller siano resi obsoleti dai modelli View.

Ho iniziato un blog su questo argomento che aggiungerò come e quando posso . Ci sono problemi con la combinazione di MVCVM con i sistemi di navigazione comuni, poiché la maggior parte dei sistemi di navigazione utilizza solo Visualizzazioni e VM, ma ne parlerò in articoli successivi.

Un ulteriore vantaggio derivante dall'utilizzo di un modello MVCVM è che nella memoria devono esistere solo gli oggetti controller per la durata dell'applicazione e che i controller contengono principalmente codice e piccoli dati di stato (ovvero piccoli overhead di memoria). Questo rende le app molto meno dispendiose in termini di memoria rispetto alle soluzioni in cui i modelli di visualizzazione devono essere mantenuti ed è ideale per alcuni tipi di sviluppo mobile (ad esempio Windows Mobile che utilizza Silverlight / Prism / MEF). Ciò dipende ovviamente dal tipo di applicazione, poiché potrebbe essere necessario conservare le macchine virtuali memorizzate nella cache occasionali per la capacità di risposta.

Nota: questo post è stato modificato numerose volte e non ha avuto come obiettivo specifico la domanda ristretta, quindi ho aggiornato la prima parte per ora anche quella. Gran parte della discussione, nei commenti seguenti, riguarda solo ASP.Net e non il quadro generale. Questo post aveva lo scopo di coprire l'uso più ampio di MVVM in Silverlight, WPF e ASP.Net e cercare di scoraggiare le persone dalla sostituzione dei controller con ViewModels.

Penso che il modo più semplice per capire cosa significhino questi acronimi è di dimenticarsene per un momento. Invece, pensa al software con cui ha avuto origine, ognuno di essi. Si riduce davvero solo alla differenza tra il Web iniziale e il desktop.

Man mano che crescevano nella complessità a metà degli anni 2000, il modello di progettazione del software MVC - descritto per la prima volta negli anni '70 - iniziò ad essere applicato alle applicazioni web. Pensa a database, pagine HTML e codice tra di loro. Rifiniamolo un po 'per arrivare a MVC: per »database«, supponiamo database più codice di interfaccia. Per »pagine HTML«, supponiamo che i modelli HTML più il codice di elaborazione dei modelli. Per »code inb Between«, supponiamo che la mappatura del codice faccia clic dagli utenti sulle azioni, che potrebbero influenzare il database, causando sicuramente la visualizzazione di un'altra vista. Questo è tutto, almeno ai fini di questo confronto.

Manteniamo una caratteristica di questa roba web, non come è oggi, ma come esisteva dieci anni fa, quando JavaScript era un fastidio modesto e spregevole, che i veri programmatori hanno fatto bene a evitare: la pagina HTML è essenzialmente stupida e passiva . Il browser è un thin client o, se vuoi, un client scadente. Non c'è intelligenza nel browser. Regola di ricarica a pagina intera. La »vista« viene generata di nuovo ogni volta.

Ricordiamo che questo modo web, nonostante fosse di gran moda, era orribilmente arretrato rispetto al desktop. Le app desktop sono fat client o rich client, se lo desideri. (Anche un programma come Microsoft Word può essere pensato come una sorta di client, un client per i documenti.) Sono client pieni di intelligenza, pieni di conoscenza dei loro dati. Sono di stato. Memorizzano nella cache i dati che stanno gestendo. Nessuna merda come una ricarica a pagina intera.

E questo ricco modo desktop è probabilmente l'origine del secondo acronimo, MVVM. Non lasciarti ingannare dalle lettere, dall'omissione dei C. Controller ci sono ancora. Devono esserlo. Nulla viene rimosso. Aggiungiamo solo una cosa: lo stato, i dati memorizzati nella cache sul client (e insieme alla sua intelligenza per gestire tali dati). Quei dati, essenzialmente una cache sul client, ora vengono chiamati »ViewModel«. È ciò che consente una ricca interattività. E questo è tutto.

• MVC = modello, controller, vista = essenzialmente comunicazione unidirezionale = scarsa interattività
• MVVM = modello, controller, cache, vista = comunicazione bidirezionale = interattività avanzata

Possiamo vedere che con Flash, Silverlight e, soprattutto, JavaScript, il Web ha abbracciato MVVM. I browser non possono più essere legittimamente chiamati thin client. Guarda la loro programmabilità. Guarda il loro consumo di memoria. Guarda tutta l'interattività Javascript sulle moderne pagine web.

Personalmente, trovo che questa teoria e l'acronimo siano più facili da capire guardando a cosa si riferisce nella realtà concreta. I concetti astratti sono utili, specialmente se dimostrati sulla materia concreta, quindi la comprensione può arrivare al punto di partenza.

MVVM Model-View ViewModel è simile a MVC, Model-View Controller

Il controller viene sostituito con un ViewModel . ViewModel si trova sotto il livello dell'interfaccia utente. ViewModel espone i dati e gli oggetti comando necessari alla vista. Potresti pensare a questo come a un oggetto contenitore da cui la vista ottiene i dati e le azioni. ViewModel estrae i suoi dati dal modello.

Russel East fa un blog discutendo più in dettaglio Perché MVVM è diverso da MVC

Per prima cosa, MVVM è una progressione del modello MVC che utilizza XAML per gestire il display. Questo articolo delinea alcune delle sfaccettature delle due.

La principale spinta dell'architettura Model / View / ViewModel sembra essere quella in cima ai dati ("il Modello"), c'è un altro livello di componenti non visivi ("il ViewModel") che mappano i concetti dei dati più da vicino ai concetti della vista dei dati ("la vista"). È il ViewModel a cui si lega la vista, non direttamente il modello.

Microsoft ha fornito una spiegazione del modello MVVM in ambiente Windows qui .

Ecco una sezione cruciale:

Nel modello di progettazione Model-View-ViewModel, un'app è composta da tre componenti generali.

• Modello : rappresenta il modello di dati utilizzato dall'app. Ad esempio, in un'app di condivisione di immagini, questo livello potrebbe rappresentare l'insieme di immagini disponibili su un dispositivo e l'API utilizzata per leggere e scrivere nella libreria di immagini.

• Visualizza : un'app è in genere composta da più pagine dell'interfaccia utente. Ogni pagina mostrata all'utente è una vista nella terminologia MVVM. La vista è il codice XAML utilizzato per definire e definire lo stile di ciò che l'utente vede. I dati del modello vengono visualizzati all'utente ed è compito del ViewModel alimentare l'interfaccia utente di questi dati in base allo stato corrente dell'app. Ad esempio, in un'app di condivisione di immagini, le viste sarebbero l'interfaccia utente che mostra all'utente l'elenco degli album sul dispositivo, le immagini in un album e forse un altro che mostra all'utente una particolare immagine.

• ViewModel : ViewModel collega il modello di dati, o semplicemente il modello, all'interfaccia utente o alle visualizzazioni dell'app. Contiene la logica con cui gestire i dati dal modello ed espone i dati come un insieme di proprietà a cui è possibile associare l'interfaccia utente o le viste XAML. Ad esempio, in un'app di condivisione di immagini, ViewModel espone un elenco di album e per ogni album espone un elenco di immagini. L'interfaccia utente è indipendente da dove provengono le immagini e come vengono recuperate. Conosce semplicemente una serie di immagini esposte dal ViewModel e le mostra all'utente.

Ho pensato che una delle differenze principali fosse che in MVC, la tua V legge direttamente la tua M e passa attraverso la C per manipolare i dati, mentre in MVVM la tua VM funge da proxy M, oltre a fornirti le funzionalità disponibili V.

Se non sono pieno di spazzatura, sono sorpreso che nessuno abbia creato un ibrido, in cui la tua VM è semplicemente un proxy M e C offre tutte le funzionalità.

MVC è un ambiente controllato e MVVM è un ambiente reattivo.

In un ambiente controllato dovresti avere meno codice e una sorgente logica comune; che dovrebbe sempre vivere all'interno del controller. Però; nel mondo web MVC si divide facilmente nella visualizzazione della logica di creazione e nella visualizzazione della logica dinamica. La creazione vive sul server e la vita dinamica sul client. Lo vedi molto con ASP.NET MVC combinato con AngularJS mentre il server creerà una vista e passerà un modello e lo invierà al client. Il client interagirà quindi con la vista, nel qual caso AngularJS interverrà come controller locale. Una volta inviato, il Modello o un nuovo Modello vengono restituiti al controller del server e gestiti. (Quindi il ciclo continua e ci sono molte altre traduzioni di questa gestione quando si lavora con socket o AJAX ecc. Ma nel complesso l'architettura è identica.)

MVVM è un ambiente reattivo, il che significa che in genere scrivi codice (come i trigger) che si attiverà in base ad un evento. In XAML, dove MVVM prospera, tutto questo è facilmente realizzabile con il framework di database integrato MA, come detto, funzionerà su qualsiasi sistema in qualsiasi View con qualsiasi linguaggio di programmazione. Non è specifico per gli Stati membri. ViewModel viene generato (in genere un evento modificato dalla proprietà) e View reagisce in base a qualsiasi trigger creato. Questo può diventare tecnico ma la linea di fondo è che la vista è senza stato e senza logica. Cambia semplicemente lo stato in base ai valori. Inoltre, i ViewModel sono apolidi con una logica molto ridotta e i modelli sono lo stato con una logica essenzialmente zero poiché dovrebbero solo mantenere lo stato. Descrivo questo come stato dell'applicazione (Modello), traduttore di stato (ViewModel) e quindi stato / interazione visiva (Visualizza).

In un'applicazione MVC desktop o lato client è necessario disporre di un modello e il modello deve essere utilizzato dal controller. In base al modello, il controller modificherà la vista. Le viste sono generalmente legate ai controller con interfacce in modo che il controller possa funzionare con una varietà di viste. In ASP.NET la logica per MVC è leggermente arretrata sul server poiché il controller gestisce i modelli e passa i modelli a una vista selezionata. La vista viene quindi riempita con i dati basati sul modello e ha la sua logica (di solito un altro set MVC come quello fatto con AngularJS). La gente discuterà e si confonderà con l'applicazione MVC e proverà a fare entrambe le cose, a quel punto il mantenimento del progetto diventerà un disastro. Metti SEMPRE la logica e il controllo in una posizione quando usi MVC. NON scrivere la logica di visualizzazione nel codice dietro la vista (o nella vista tramite JS per il Web) per contenere i dati del controller o del modello. Consenti al controller di modificare la vista. L'UNICA logica che dovrebbe vivere in una vista è tutto ciò che serve per creare ed eseguire tramite l'interfaccia che sta utilizzando. Un esempio di questo è l'invio di un nome utente e una password. Se il desktop o la pagina Web (sul client), il controller deve gestire il processo di invio ogni volta che la vista attiva l'azione di invio. Se eseguito correttamente, puoi sempre orientarti facilmente su un Web MVC o un'app locale. Se il desktop o la pagina Web (sul client), il controller deve gestire il processo di invio ogni volta che la vista attiva l'azione di invio. Se eseguito correttamente, puoi sempre orientarti facilmente in un Web MVC o in un'app locale. Se il desktop o la pagina Web (sul client), il controller deve gestire il processo di invio ogni volta che la vista attiva l'azione di invio. Se eseguito correttamente, puoi sempre orientarti facilmente in un Web MVC o in un'app locale.

MVVM è personalmente il mio preferito in quanto completamente reattivo. Se un modello cambia, ViewModel ascolta e traduce quello stato ed è tutto !!! La vista quindi ascolta ViewModel per il cambio di stato e si aggiorna anche in base alla traduzione da ViewModel. Alcune persone lo chiamano MVVM puro ma ce n'è davvero solo uno e non mi interessa come lo argomenti ed è sempre MVVM puro in cui la vista non contiene assolutamente alcuna logica.

Ecco un piccolo esempio: supponiamo che tu voglia far scorrere un menu alla pressione di un pulsante. In MVC avrai un'azione MenuPressed nella tua interfaccia. Il controller saprà quando si fa clic sul pulsante Menu e quindi indica alla vista di scorrere nel menu in base a un altro metodo di interfaccia come SlideMenuIn. Un viaggio di andata e ritorno per quale motivo? Nel caso in cui il Controller decida che non puoi o vuoi fare qualcos'altro, è per questo che. Il controller dovrebbe essere responsabile della vista con la vista che non fa nulla a meno che non lo dica il controllore. PERÒ; in MVVM il menu delle diapositive nell'animazione dovrebbe essere integrato e generico e invece di essere detto di farlo scorrere lo farà in base a un valore. Quindi ascolta ViewModel e quando ViewModel dice, IsMenuActive = true (o comunque) l'animazione per quello ha luogo. Adesso, Detto questo, voglio fare un altro punto DAVVERO CHIARO e PER FAVORE presta attenzione. IsMenuActive è probabilmente BAD MVVM o ViewModel design. Quando si progetta un ViewModel non si deve mai supporre che una vista abbia delle caratteristiche e che passi semplicemente lo stato del modello tradotto. In questo modo, se decidi di modificare la visualizzazione per rimuovere il menu e mostrare semplicemente i dati / le opzioni in un altro modo, a ViewModel non importa. Quindi come gestiresti il ​​menu? Quando i dati hanno senso, ecco come. Quindi, un modo per farlo è quello di dare al Menu un elenco di opzioni (probabilmente una matrice di ViewModels interni). Se tale elenco contiene dati, il Menu allora sa aprirsi tramite il trigger, in caso contrario sa nascondersi tramite il trigger. Hai semplicemente dati per il menu o no nel ViewModel. NON decidere di mostrare / nascondere quei dati nel ViewModel .. tradurre semplicemente lo stato del modello. In questo modo la vista è completamente reattiva e generica e può essere utilizzata in diverse situazioni.

Tutto ciò probabilmente non ha assolutamente senso se non hai già almeno una certa familiarità con l'architettura di ciascuno e apprenderlo può essere molto confuso poiché troverai molte informazioni MALE sulla rete.

Quindi ... cose da tenere a mente per farlo bene. Decidi in anticipo come progettare la tua applicazione e STICK TO IT.

Se esegui MVC, il che è fantastico, assicurati che il tuo controller sia gestibile e in pieno controllo della tua vista. Se si dispone di una vista di grandi dimensioni, prendere in considerazione l'aggiunta di controlli alla vista con controller diversi. NON SOLO cascata quei controller su controller diversi. Molto frustrante da mantenere. Prenditi un momento e progetta le cose separatamente in modo che funzionino come componenti separati ... E lascia sempre che il Controller dica al Modello di impegnare o persistere la memorizzazione. L'impostazione della dipendenza ideale per MVC in è Visualizza ← Controller → Modello o con ASP.NET (non iniziare) Modello ← Visualizza ↔ Controller → Modello (in cui il modello può essere lo stesso o un modello completamente diverso dal controller alla vista) ... ovviamente l'unica necessità di conoscere Controller in View a questo punto è principalmente per riferimento endpoint per sapere dove tornare per passare un Modello.

Se fai MVVM, benedico la tua anima gentile, ma prenditi il ​​tempo per farlo GIUSTO! Non utilizzare interfacce per uno. Lascia che la tua vista decida come apparirà in base ai valori. Gioca con i dati View with Mock. Se finisci per avere una vista che ti mostra un menu (come nell'esempio) anche se al momento non lo volevi, allora BUONO. Il tuo punto di vista funziona come dovrebbe e reagisce in base ai valori come dovrebbe. Basta aggiungere alcuni requisiti al trigger per assicurarsi che ciò non accada quando ViewModel si trova in un particolare stato tradotto o comandare ViewModel per svuotare questo stato. Nel ViewModel NON rimuoverlo con la logica interna, come se decidessi da lì se la View dovrebbe vederlo o meno. Ricorda che non puoi presumere che ci sia un menu o meno nel ViewModel. E infine, il modello dovrebbe consentire solo di cambiare e molto probabilmente lo stato del negozio. Questo è dove la validazione e tutto avverrà; ad esempio, se il Modello non è in grado di modificare lo stato, verrà semplicemente contrassegnato come sporco o simile. Quando ViewModel si rende conto di ciò, tradurrà ciò che è sporco, e View lo realizzerà e mostrerà alcune informazioni tramite un altro trigger. Tutti i dati nella vista possono essere associati a ViewModel, quindi tutto può essere dinamico solo il modello e ViewModel non ha assolutamente idea di come la vista reagirà all'associazione. È un dato di fatto che il Modello non ha nemmeno idea di un ViewModel. Quando si impostano le dipendenze dovrebbero puntare così e solo così Per modificare lo stato, sarà semplicemente contrassegnato come sporco o simile. Quando ViewModel si rende conto di ciò, tradurrà ciò che è sporco, e View lo realizzerà e mostrerà alcune informazioni tramite un altro trigger. Tutti i dati nella vista possono essere associati a ViewModel, quindi tutto può essere dinamico solo il modello e ViewModel non ha assolutamente idea di come la vista reagirà all'associazione. È un dato di fatto che il Modello non ha nemmeno idea di un ViewModel. Quando si impostano le dipendenze dovrebbero puntare così e solo così Per modificare lo stato, sarà semplicemente contrassegnato come sporco o simile. Quando ViewModel si rende conto di ciò, tradurrà ciò che è sporco, e View lo realizzerà e mostrerà alcune informazioni tramite un altro trigger. Tutti i dati nella vista possono essere associati a ViewModel, quindi tutto può essere dinamico solo il modello e ViewModel non ha assolutamente idea di come la vista reagirà all'associazione. È un dato di fatto che il Modello non ha nemmeno idea di un ViewModel. Quando si impostano le dipendenze dovrebbero puntare così e solo così Tutti i dati nella vista possono essere associati a ViewModel, quindi tutto può essere dinamico solo il modello e ViewModel non ha assolutamente idea di come la vista reagirà all'associazione. È un dato di fatto che il Modello non ha nemmeno idea di un ViewModel. Quando si impostano le dipendenze dovrebbero puntare così e solo così Tutti i dati nella vista possono essere associati a ViewModel, quindi tutto può essere dinamico solo il modello e ViewModel non ha assolutamente idea di come la vista reagirà all'associazione. È un dato di fatto che il Modello non ha nemmeno idea di un ViewModel. Quando si impostano le dipendenze dovrebbero puntare così e solo cosìVisualizza → ViewModel → Modello (e una nota a margine qui ... e probabilmente anche questo verrà discusso, ma non mi interessa ... NON PASSARE IL MODELLO ALLA VISUALIZZAZIONE a meno che quel MODELLO non sia immutabile; altrimenti avvolgilo con un ViewModel corretto. La vista non dovrebbe vedere un periodo di modello. Dò a un ratto il crack che demo hai visto o come lo hai fatto, è sbagliato.)

Ecco il mio consiglio finale ... Guarda un'applicazione MVC ben progettata, ma molto semplice, e fai lo stesso per un'applicazione MVVM. Uno avrà un maggiore controllo con flessibilità limitata a zero, mentre l'altro non avrà alcun controllo e flessibilità illimitata.

Un ambiente controllato è utile per la gestione dell'intera applicazione da un set di controller o (una singola fonte) mentre un ambiente reattivo può essere suddiviso in repository separati senza assolutamente idea di cosa stia facendo il resto dell'applicazione. Gestione micro vs gestione gratuita.

Se non ti ho confuso abbastanza prova a contattarmi ... Non mi dispiace andare su questo in dettaglio con illustrazioni ed esempi.

Alla fine della giornata siamo tutti programmatori e con quell'anarchia vive dentro di noi quando si codifica ... Quindi le regole verranno infrante, le teorie cambieranno e tutto questo finirà per lavarsi il maiale ... Ma quando si lavora su grandi progetti e in team di grandi dimensioni, aiuta davvero a concordare un modello di progettazione e applicarlo. Un giorno renderà i piccoli passi in più intrapresi all'inizio diventeranno balzi e limiti di risparmio in seguito.

Differenza semplice: (ispirato al corso Coursera AngularJS di Yaakov)

MVC (Model View Controller)

1. Modelli: i modelli contengono informazioni sui dati. Non chiama né utilizza Controller e View. Contiene la logica aziendale e i modi per rappresentare i dati. Alcuni di questi dati, in qualche modo, possono essere visualizzati nella vista. Può anche contenere la logica per recuperare i dati da qualche sorgente.
2. Controller: funge da connessione tra vista e modello. Visualizza chiamate Controller e Controller chiama il modello. In sostanza informa il modello e / o la vista per cambiare nel modo appropriato.
3. Visualizza: offerte con parte dell'interfaccia utente. Interagisce con l'utente.

MVVM (Model View View Model)

ViewModel :

1. È la rappresentazione dello stato della vista.
2. Contiene i dati visualizzati nella vista.
3. Risponde per visualizzare gli eventi, ovvero la logica di presentazione.
4. Chiama altre funzionalità per l'elaborazione della logica aziendale.
5. Non chiede mai direttamente alla vista di visualizzare nulla.

MVVM è un perfezionamento (discutibile) del modello del modello di presentazione. Dico discutibile, perché l'unica differenza è nel modo in cui WPF offre la possibilità di eseguire l'associazione dei dati e la gestione dei comandi.

Il viewmodel è un modello "astratto" per gli elementi dell'interfaccia utente. Deve consentire all'utente di eseguire i comandi e le azioni nella vista in modo non visivo (ad esempio per testarlo).

Se hai lavorato con MVC, probabilmente hai trovato utile a volte creare oggetti modello per riflettere lo stato della tua vista, ad esempio per mostrare e nascondere alcune finestre di dialogo di modifica, ecc. In tal caso stai usando un modello di visualizzazione.

Il modello MVVM è semplicemente la generalizzazione di quella pratica a tutti gli elementi dell'interfaccia utente.

E non è un modello Microsoft, ciò che aggiunge è che i binding di dati WPF / Silverlight sono particolarmente adatti per lavorare con questo modello. Ma nulla ti impedisce di usarlo con le facce del server Java, ad esempio.

Le altre risposte potrebbero non essere facili da capire per chi non ha molta familiarità con l'argomento dei motivi architettonici. Qualcuno che non conosce l'architettura delle app potrebbe voler sapere in che modo la sua scelta può influire sulla sua app in pratica e di cosa si tratta nelle storie.

Cercando di far luce su quanto sopra, ho inventato questa sceneggiatura che coinvolge MVVM, MVP e MVC. La storia inizia quando un utente fa clic sul pulsante "TROVA" in un'app di ricerca di filmati ...:

Utente: fare clic su ...

Visualizza : chi è quello? [ MVVM | MVP | MVC ]

Utente: ho appena fatto clic sul pulsante di ricerca ...

Visualizza : Ok, aspetta un secondo .... [ MVVM | MVP | MVC ]

( Visualizza chiamando il ViewModel | Presenter | Controller ...) [ MVVM | MVP | MVC ]

Visualizza : Hey ViewModel | Presentatore | Controller , un utente ha appena fatto clic sul pulsante di ricerca, cosa devo fare? [ MVVM | MVP | MVC ]

ViewModel | Presentatore | Controller : Hey View , c'è un termine di ricerca su quella pagina? [ MVVM | MVP | MVC ]

Visualizza : Sì, eccolo ... "piano" [ MVVM | MVP | MVC ]

—— Questa è la differenza più importante tra MVVM E MVP | MVC ———

Presentatore : Grazie Visualizza , ... nel frattempo sto cercando il termine di ricerca sul Modello , per favore mostragli una barra di avanzamento [ MVP | MVC ]

( Presentatore | Il controller chiama il modello ...) [ MVP | MVC ]

ViewController : Grazie, cercherò il termine di ricerca sul Modello ma non ti aggiornerò direttamente. Invece, attiverò gli eventi in searchResultsListObservable se c'è qualche risultato. Quindi faresti meglio a osservarlo. [ MVVM ]

(Mentre osserva qualsiasi trigger in searchResultsListObservable, la vista pensa che dovrebbe mostrare all'utente una barra di avanzamento, dal momento che ViewModel non ci parla su di esso)

------------------------------

ViewModel | Presentatore | Controller : Hey Model , hai qualche corrispondenza con questo termine di ricerca ?: "piano" [ MVVM | MVP | MVC ]

Modello : Hey ViewModel | Presentatore | Controller , fammi controllare ... [ MVVM | MVP | MVC ]

(Il modello sta eseguendo una query nel database del film ...) [ MVVM | MVP | MVC ]

( Dopo un po … )

———— Questo è il punto di divergenza tra MVVM , MVP e MVC ————–

Modello : ho trovato un elenco per te, ViewModel | Presentatore , eccolo in JSON "[{" name ":" Piano Teacher "," year ": 2001}, {" name ":" Piano "," year ": 1993}]" [ MVVM | MVP ]

Modello : sono disponibili dei risultati, controller. Ho creato una variabile di campo nella mia istanza e l'ho riempita con il risultato. Il suo nome è "searchResultsList" [ MVC ]

( Presentatore | Controller ringrazia Model e torna alla vista ) [ MVP | MVC ]

Presentatore : Grazie per l'attesa di View , ho trovato un elenco di risultati corrispondenti per te e li ho organizzati in un formato presentabile: ["Piano Teacher 2001 ″," Piano 1993 "]. Inoltre, nascondi ora la barra di avanzamento [ MVP ]

Controller : Grazie per aver atteso View , ho chiesto a Model la tua query di ricerca. Dice che ha trovato un elenco di risultati corrispondenti e li ha memorizzati in una variabile denominata "searchResultsList" all'interno della sua istanza. Puoi ottenerlo da lì. Inoltre, nascondi ora la barra di avanzamento [ MVC ]

ViewModel : qualsiasi osservatore su searchResultsListObservable viene informato che esiste questo nuovo elenco in formato presentabile: ["Piano Teacher 2001 ″," Piano 1993 "]. [ MVVM ]

Visualizza : Grazie mille Presentatore [ MVP ]

Visualizza : Grazie " Controller " [ MVC ] (Ora la View si sta interrogando: come devo presentare all'utente i risultati che ottengo dal Modello ? L'anno di produzione del film dovrebbe essere il primo o l'ultimo ...?)

Visualizza : Oh, c'è un nuovo trigger in searchResultsListObservable ..., bene, c'è un elenco presentabile, ora devo solo mostrarlo in un elenco. Dovrei anche nascondere la barra di avanzamento ora che ho il risultato. [ MVVM ]

Nel caso tu sia interessato, ho scritto una serie di articoli qui , confrontando MVVM, MVP e MVC implementando un'app Android per la ricerca di film.

Iniezione di ViewModels fortemente tipizzati nella vista mediante MVC

1. Il controller è responsabile per la nuova creazione di ViewModel e l'iniezione nella View. (per ottenere richieste)
2. ViewModel è il contenitore per DataContext e lo stato di visualizzazione come l'ultimo elemento selezionato ecc.
3. Il modello contiene entità DB ed è molto vicino allo schema DB che esegue le query e il filtro. (Mi piacciono EF e LINQ per questo)
4. Il modello dovrebbe anche prendere in considerazione i repository e / o la proiezione dei risultati in tipi forti (EF ha un ottimo metodo ... EF.Database.Select (querystring, parms) per l'accesso diretto ADO per iniettare query e ottenere tipi forti. è un argomento lento. EF NON È LENTO !
5. ViewModel ottiene i dati ed esegue le regole aziendali e la convalida
6. Il controller sul post back chiamerà il metodo ViewModel Post e attenderà i risultati.
7. Il controller inietterà il Viewmodel appena aggiornato nella visualizzazione. La vista utilizza solo un'associazione di tipo forte .
8. La vista esegue semplicemente il rendering dei dati e riporta gli eventi al controller. (vedi esempi sotto)
9. MVC intercetta la richiesta in entrata e la inoltra al controller corretto con un tipo di dati sicuro

In questo modello non esiste più un contatto a livello HTTP con gli oggetti richiesta o risposta poiché la macchina MVC di MSFT lo nasconde da noi.

Chiarimento del punto 6 sopra (su richiesta) ...

Assumi un ViewModel come questo:

public class myViewModel{
     public string SelectedValue {get;set;}
public void Post(){
    //due to MVC model binding the SelectedValue string above will be set by MVC model binding on post back.
    //this allows you to do something with it.
    DoSomeThingWith(SelectedValue);
    SelectedValue = "Thanks for update!";
 }
}

Il metodo del controller del post apparirà così (Vedi sotto), nota che l'istanza di mvm viene automaticamente istanziata dai meccanismi di associazione MVC. Di conseguenza, non devi mai passare al livello stringa di query! Questo è MVC che crea l'istanza di ViewModel per te in base alle stringhe di query!

[HTTPPOST]   
public ActionResult MyPostBackMethod (myViewModel mvm){
         if (ModelState.IsValid)
        {
               // Immediately call the only method needed in VM...
               mvm.Post()
        }
      return View(mvm);
}

Si noti che affinché questo metodo di azione sopra funzioni come previsto, è necessario definire un CTOR null che inizializzi le cose non restituite nel post. Il post back deve anche postare back coppie nome / valore per quelle cose che sono cambiate. Se mancano coppie nome / valore mancanti, il motore di bind MVC fa la cosa giusta che è semplicemente nulla! In questo caso potresti ritrovarti a dire "Sto perdendo i dati sui post back" ...

Il vantaggio di questo modello è che ViewModel fa tutto il lavoro "disordinato" interfacciarsi con la logica Model / Buisness, il controller è semplicemente una sorta di router. È SOC in azione.

MVVM aggiunge il modello di visualizzazione nel mix. Questo è importante, in quanto ti consente di utilizzare molto l'approccio vincolante di WPF, senza mettere tutti quei pezzi specifici dell'interfaccia utente nel tuo modello normale.

Potrei sbagliarmi, ma non sono sicuro che MVVM costringa davvero il controller nel mix. Trovo che il concetto sia più in linea con: http://martinfowler.com/eaaDev/PresentationModel.html . Penso che la gente scelga di combinarlo con MVC, non che sia integrato nel modello.

Da quello che posso dire, l'MVVM si associa all'MV di MVC, il che significa che in un modello MVC tradizionale la V non comunica direttamente con M. Nella seconda versione di MVC, esiste un collegamento diretto tra M e V. MVVM sembra assumere tutte le attività relative alla comunicazione M e V e accoppiarla per separarla dalla C. In effetti, c'è ancora il flusso di lavoro delle applicazioni con ambito più ampio (o l'implementazione degli scenari di utilizzo) che non sono completamente presi in considerazione in MVVM. Questo è il ruolo del controller. Rimuovendo questi aspetti di livello inferiore dai controller, sono più puliti e facilitano la modifica dello scenario di utilizzo dell'applicazione e della logica aziendale, rendendo anche i controller più riutilizzabili.

Mi sorprende che questa sia una risposta molto votata senza menzionare l' origine di MVVM. MVVM è un termine popolare utilizzato nella comunità Microsoft ed è derivato dal modello di presentazione di Martin Fowler . Quindi, per capire il motivo del modello e le differenze con gli altri, l'articolo originale sul modello è la prima cosa da leggere.

Bene, generalmente MVC viene utilizzato nello sviluppo Web e MVVM è più popolare nello sviluppo WPF / Silverlight. Tuttavia, a volte il web architecute potrebbe avere un mix di MVC e MVVM.

Ad esempio: potresti usare knockout.js e in questo caso avrai MVVM sul tuo lato client. E anche il lato server del tuo MVC può cambiare. Nelle app complesse, nessuno usa il modello puro. Potrebbe avere senso usare un ViewModel come "Modello" di MVC e il tuo Modello reale in pratica farà parte di questa VM. Questo ti dà un ulteriore livello di astrazione.

MVVMC, o forse MVC +, sembra essere un approccio praticabile per le aziende e per un rapido sviluppo delle applicazioni. Mentre è bello separare l'interfaccia utente dalla logica di business e di interazione, il modello MVVM "puro" e gli esempi più disponibili funzionano meglio su viste singolari.

Non sono sicuro dei tuoi progetti, ma la maggior parte delle mie applicazioni, tuttavia, contiene pagine e diverse visualizzazioni (riutilizzabili) e quindi i ViewModel devono interagire in una certa misura. L'uso della pagina come controller annullerebbe del tutto lo scopo di MVVM, quindi non usare un approccio "VM-C" per la logica sottostante potrebbe comportare ... beh ... costrutti impegnativi man mano che l'applicazione matura. Anche in VB-6 la maggior parte di noi probabilmente ha smesso di codificare la logica di business nell'evento Button e ha iniziato a "inoltrare" i comandi a un controller, giusto? Di recente ho esaminato molti quadri emergenti su questo argomento; il mio preferito è chiaramente l'approccio di Magellan (al codeplex). Buona programmazione!

http://en.wikipedia.org/wiki/Model_View_ViewModel#References

Il controller non viene sostituito da un ViewModel in MVVM, poiché ViewModel ha una funzionalità totalmente diversa rispetto a un controller. Hai ancora bisogno di un controller, perché senza un controller il tuo modello, ViewModel e View non faranno molto ... In MVVM hai anche un controller, il nome MVVM è semplicemente fuorviante.

MVVMC è il nome corretto secondo la mia modesta opinione.

Come puoi vedere, ViewModel è solo un'aggiunta al modello MVC. Sposta la logica di conversione (ad esempio convertire l'oggetto in una stringa) dal controller al ViewModel.

Ho realizzato un articolo Medium per questo.

MVVM

1. Visualizza ➡ ViewModel ➡ Modello

   • La vista ha un riferimento a ViewModel ma non viceversa.
   • ViewModel ha un riferimento al modello ma non viceversa.
   • La vista non ha riferimenti al modello e viceversa.

2. Se si utilizza un controller, può avere un riferimento a Views e ViewModels , sebbene un controller non sia sempre necessario, come dimostrato in SwiftUI .

3. Data Binding : creiamo listener per ViewModel Properties.

class CustomView: UIView {
  var viewModel = MyViewModel {
    didSet {
      self.color = viewModel.color
    }
  }

  convenience init(viewModel: MyViewModel) {
    self.viewModel = viewModel
  }
}


struct MyViewModel {
   var viewColor: UIColor {
      didSet {
         colorChanged?() // This is where the binding magic happens.
      }
   }

   var colorChanged: ((UIColor) -> Void)?
}


class MyViewController: UIViewController {

   let myViewModel = MyViewModel(viewColor: .green)
   let customView: CustomView!

   override func viewDidLoad() {
      super.viewDidLoad()

      // This is where the binder is assigned.
      myViewModel.colorChanged = { [weak self] color in 
        print("wow the color changed")
      }
      customView = CustomView(viewModel: myViewModel)
      self.view = customView
   }
}

differenze nella configurazione

1. La logica aziendale si trova nel controller per MVC e ViewModels per MVVM.
2. Gli eventi vengono passati direttamente dalla vista al controller in MVC mentre gli eventi vengono passati dalla vista al ViewModel al controller (se presente) per MVVM.

Caratteristiche comuni

1. Sia MVVM che MVC non consentono alla Vista di inviare messaggi direttamente al Modello / i.
2. Entrambi hanno modelli.
3. Entrambi hanno una vista.

Vantaggi di MVVM

1. Poiché i ViewModel possiedono una logica aziendale, sono oggetti concreti più piccoli che li rendono facili da testare. D'altra parte, in MVC, la logica aziendale è nel ViewController. Come puoi fidarti che un test unitario di un controller di visualizzazione è completamente sicuro senza testare contemporaneamente tutti i metodi e i listener? Non puoi fidarti completamente dei risultati del test unitario.
2. In MVVM, poiché la logica aziendale viene trasferita dal controller in unità atomiche ViewModel, le dimensioni di ViewController si riducono e ciò rende il codice ViewController più leggibile.

Vantaggi di MVC

1. Fornire la logica aziendale all'interno del controller riduce la necessità di ramificazioni e pertanto è più probabile che le istruzioni vengano eseguite nella cache, che è più performante rispetto all'incapsulamento della logica aziendale in ViewModels.
2. Fornire la logica di business in un unico posto può accelerare il processo di sviluppo per applicazioni semplici, dove non sono richiesti test. Non so quando i test non sono richiesti.
3. Fornire la logica aziendale nel ViewController è più facile da pensare per i nuovi sviluppatori.

Da un punto di vista pratico, MVC (Model-View-Controller) è un modello. Tuttavia, MVC quando usato come ASP.net MVC, quando combinato con Entity Framework (EF) e gli "strumenti di potere" è un approccio molto potente, parzialmente automatizzato per portare database, tabelle e colonne in una pagina Web, sia per Operazioni CRUD o solo operazioni R (Recupera o Leggi). Almeno mentre usavo MVVM, i View View interagivano con i modelli che dipendevano da oggetti business, che erano a loro volta "fatti a mano" e dopo un sacco di sforzi, si era fortunati a ottenere modelli buoni come quelli che EF offre " -of-the-box". Da un punto di vista pratico della programmazione, MVC sembra una buona scelta perché offre un sacco di utilità pronta per l'uso, ma c'è ancora un potenziale per l'aggiunta di campane e fischietti.

Complementare a molte delle risposte fornite, volevo aggiungere qualche prospettiva aggiuntiva dal Web lato client moderno o dal punto di vista dell'applicazione Web ricca .

Al giorno d'oggi, infatti, siti Web semplici e applicazioni Web più grandi vengono comunemente creati con molte librerie popolari come Bootstrap. Creato da Steve Sanderson, Knockout fornisce supporto per il modello MVVM che imita uno dei comportamenti più importanti nel modello: l'associazione dei dati attraverso il modello di visualizzazione. Con un po 'di JavaScript, è possibile implementare dati e logica che possono essere aggiunti agli elementi della pagina con semplici data-bindattributi HTML, in modo simile all'utilizzo di molte delle funzionalità di Bootstrap . Insieme, solo queste due biblioteche offrono contenuti interattivi; e quando combinato con il routing questo approccio può tradursi in un approccio semplice ma potente per la creazione dell'applicazione a pagina singola .

Allo stesso modo, un framework moderno lato client come Angular segue il modello MVC per convenzione, ma aggiunge anche un servizio. È interessante notare che è propagandato come Model-View-qualunque (MVW). (Vedi questo post su Stack Overflow .)

Inoltre, con l'ascesa di framework Web progressivi come Angular 2, stiamo assistendo a un cambiamento nella terminologia e forse a un nuovo modello architettonico in cui i componenti comprendono una vista o un modello e interagiscono con un servizio, tutti elementi che possono essere contenuti in un Modulo; e una serie di moduli costituisce l'applicazione.

Pensavo che MVC e MVVM fossero uguali. Ora, a causa dell'esistenza di Flux, posso dire la differenza:

In MVC, per ogni vista nella tua app, hai un modello e un controller, quindi lo chiamerei view, view model, view controller. Il modello non ti dice come una vista può comunicare con un'altra. Pertanto, in diversi contesti ci sono diverse implementazioni per questo. Ad esempio ci sono implementazioni in cui i controller parlano tra loro mentre in altre implementazioni c'è un altro componente che media tra loro. Esistono persino implementazioni in cui i modelli di vista comunicano tra loro, il che rappresenta un'interruzione del modello MVC perché il modello della vista deve accedere solo al controller della vista.

In MVVM, hai anche un modello di visualizzazione per ciascun componente. Il modello non specifica in che modo la vista dovrebbe influenzare il modello di vista, quindi di solito la maggior parte dei framework include solo la funzionalità del controller nel modello di vista. Tuttavia, MVVM ti dice che i dati del tuo modello di vista dovrebbero provenire dal modello, che è l'intero modello che non è a conoscenza o personalizzato per una vista specifica.

Per dimostrare la differenza, prendiamo il modello Flux. Il modello di flusso indica come dovrebbero comunicare le diverse viste nell'app. Ogni vista ascolta un negozio e attiva azioni utilizzando il dispatcher. Il dispatcher a sua volta informa tutti i negozi sull'azione che è stata appena effettuata e i negozi si aggiornano da soli. Un negozio in Flux corrisponde al modello (generale) in MVVM. non è personalizzato per nessuna vista specifica. Di solito, quando le persone usano React e Flux, ciascun componente React implementa effettivamente il modello MVVM. Quando si verifica un'azione, il modello di visualizzazione chiama il dispatcher e infine viene aggiornato in base alle modifiche nel negozio, che è il modello. Non si può dire che ogni componente implementa MVC perché in MVC solo il controller può aggiornare il modello di visualizzazione.

mvc è lato server e mvvm è lato client (browser) nello sviluppo web.

il più delle volte javascript viene utilizzato per mvvm nel browser. ci sono molte tecnologie lato server per mvc.

In breve: MVC Controler è a conoscenza della vista (controlli), mentre in MVVM ViewModel non è consapevole di chi lo consuma. ViewModel espone le sue proprietà e azioni osservabili a chiunque possa essere interessato a usarlo. Questo fatto semplifica i test poiché non esiste alcun riferimento all'interfaccia utente in ViewModel.

Model – View – Controller (generalmente noto come MVC ) è un modello di progettazione software comunemente utilizzato per lo sviluppo di interfacce utente che divide la logica del programma correlata in tre elementi interconnessi. Questo viene fatto per separare le rappresentazioni interne delle informazioni dal modo in cui le informazioni vengono presentate e accettate dall'utente. Seguendo il modello architettonico MVC si disaccoppiano questi componenti principali consentendo il riutilizzo del codice e lo sviluppo parallelo.

Utilizzato tradizionalmente per le interfacce utente grafiche desktop (GUI), questo modello è diventato popolare per la progettazione di applicazioni Web. I linguaggi di programmazione più diffusi come JavaScript, Python, Ruby, PHP, Java e C # hanno framework MVC che vengono immediatamente utilizzati nello sviluppo di applicazioni web.

Modello

Il componente centrale del modello. È la struttura dinamica dei dati dell'applicazione, indipendente dall'interfaccia utente. Gestisce direttamente i dati, la logica e le regole dell'applicazione.

Visualizza

Qualsiasi rappresentazione di informazioni come un grafico, un diagramma o una tabella. Sono possibili più viste delle stesse informazioni, come un grafico a barre per la gestione e una vista tabulare per i contabili.

controllore

Accetta l'input e lo converte in comandi per il modello o la vista.

Oltre a dividere l'applicazione in questi componenti, il design del modello vista-controller definisce le interazioni tra di loro.

Il modello è responsabile della gestione dei dati dell'applicazione. Riceve l'input dell'utente dal controller.

La vista indica una presentazione del modello in un formato particolare.

Il controller risponde all'input dell'utente ed esegue interazioni sugli oggetti del modello dati. Il controller riceve l'input, facoltativamente lo convalida e quindi passa l'input al modello.

Model – View – ViewModel (MVVM) è un modello architettonico del software.

MVVM facilita una separazione dello sviluppo dell'interfaccia utente grafica, sia tramite un linguaggio di markup o un codice GUI, dallo sviluppo della logica di business o della logica di back-end (il modello di dati). Il modello di vista di MVVM è un convertitore di valore, il che significa che il modello di vista è responsabile dell'esposizione (conversione) degli oggetti dati dal modello in modo tale che gli oggetti possano essere facilmente gestiti e presentati. A questo proposito, il modello di vista è più modello di una vista e gestisce la maggior parte, se non tutta, la logica di visualizzazione della vista. Il modello di vista può implementare un modello mediatore, organizzando l'accesso alla logica di back-end attorno all'insieme di casi d'uso supportati dalla vista.

MVVM è una variante del modello di progettazione del modello di presentazione di Martin Fowler. MVVM astrae lo stato e il comportamento di una vista allo stesso modo, ma un modello di presentazione astrae una vista (crea un modello di vista) in un modo non dipendente da una piattaforma di interfaccia utente specifica.

MVVM è stato inventato dagli architetti Microsoft Ken Cooper e Ted Peters specificamente per semplificare la programmazione basata su eventi delle interfacce utente. Il modello è stato incorporato in Windows Presentation Foundation (WPF) (sistema grafico .NET di Microsoft) e Silverlight (derivato dell'applicazione Internet di WPF). John Gossman, uno degli architetti WPF e Silverlight di Microsoft, ha annunciato MVVM sul suo blog nel 2005.

Model – View – ViewModel è anche definito modello-view – binder, in particolare nelle implementazioni che non coinvolgono la piattaforma .NET. ZK (un framework di applicazioni Web scritto in Java) e KnockoutJS (una libreria JavaScript) usano il modello-view-binder.