Cosa sono MVP e MVC e qual è la differenza?

2133

Quando si guarda oltre il modo RAD (trascinamento della selezione e configurazione) di creare interfacce utente che molti strumenti incoraggiano, è probabile che si verifichino tre modelli di progettazione chiamati Model-View-Controller , Model-View-Presenter e Model-View-ViewModel . La mia domanda ha tre parti:

A quali problemi affrontano questi schemi?
Come sono simili?
Come sono differenti?

— Mike Minutillo
fonte

4

mvc.givan.se/#mvp

— givanse l'

2

IDK, ma presumibilmente per l'MVC originale, doveva essere utilizzato nel piccolo. Ogni pulsante, etichetta, ecc. Aveva la sua "vista e oggetto controller", o almeno questo è ciò che sostiene lo zio Bob. Penso che stesse parlando di Smalltalk. Guarda i suoi discorsi su YouTube, sono affascinanti.

— still_dreaming_1,

MVP aggiunge un ulteriore livello di riferimento indiretto suddividendo il View-Controller in una vista e un presentatore ...

— the_prole

2

La differenza principale è che in MVC il controller non passa alcun dato dal modello alla vista. Notifica semplicemente alla vista di ottenere i dati dal modello stesso. Tuttavia, in MVP non esiste alcuna connessione tra la vista e il modello. Il Presenter stesso riceve tutti i dati necessari dal Modello e li passa alla Visualizzazione per mostrarli. Altro su questo insieme a un campione Android in tutti i modelli di architettura è qui: digigene.com/category/android/android-architecture

— Ali Nem

Si chiamano modelli architettonici e non modelli di progettazione . Se vuoi sapere la differenza, controlla questo

— Hasan El-Hefnawy,

1997

Model-View-Presenter

In MVP , Presenter contiene la logica di business dell'interfaccia utente per la vista. Tutte le invocazioni dal delegato Visualizza direttamente a Presenter. Il Presenter viene anche disaccoppiato direttamente dalla Vista e ci parla attraverso un'interfaccia. Questo per consentire di deridere la vista in un test unitario. Un attributo comune di MVP è che ci deve essere un sacco di dispacciamento bidirezionale. Ad esempio, quando qualcuno fa clic sul pulsante "Salva", il gestore eventi delega al metodo "OnSave" del relatore. Una volta completato il salvataggio, il Presenter richiamerà la vista attraverso la sua interfaccia in modo che la vista possa visualizzare che il salvataggio è stato completato.

MVP tende ad essere un modello molto naturale per ottenere una presentazione separata in Web Form. Il motivo è che la vista viene sempre creata prima dal runtime ASP.NET. Puoi scoprire di più su entrambe le varianti .

Due varianti principali

Vista passiva: la vista è il più stupida possibile e contiene una logica quasi nulla. Il presentatore è un uomo di mezzo che parla con la vista e il modello. La vista e il modello sono completamente schermati l'uno dall'altro. Il modello può generare eventi, ma il relatore si abbona ad essi per l'aggiornamento della vista. Nella vista passiva non esiste alcun legame diretto con i dati, invece la vista espone le proprietà del setter che il relatore utilizza per impostare i dati. Tutto lo stato è gestito nel Presenter e non nella Vista.

Pro: massima superficie di testabilità; separazione netta della vista e del modello
Contro: più lavoro (ad esempio tutte le proprietà del setter) mentre si stanno eseguendo tutti i dati da soli.

Supervisore del controller: Presenter gestisce i gesti degli utenti. La vista si lega direttamente al modello tramite l'associazione dei dati. In questo caso è compito del Presentatore passare il Modello alla Vista in modo che possa legarsi ad esso. Il Presenter conterrà anche la logica per gesti come la pressione di un pulsante, la navigazione, ecc.

Pro: sfruttando il databinding si riduce la quantità di codice.
Contro: c'è meno superficie testabile (a causa dell'associazione dei dati) e c'è meno incapsulamento nella vista poiché parla direttamente al modello.

Model-View-Controller

Nel MVC , il controller è responsabile per determinare quali View per visualizzare in risposta a qualsiasi azione anche quando l'applicazione carica. Ciò differisce da MVP in cui le azioni vengono instradate attraverso la vista al presentatore. In MVC, ogni azione nella Vista è correlata a una chiamata a un Controller insieme a un'azione. Nel web ogni azione comporta una chiamata a un URL dall'altra parte del quale c'è un controller che risponde. Una volta che il controller ha completato l'elaborazione, restituirà la vista corretta. La sequenza continua in questo modo per tutta la durata dell'applicazione:

    Azione nella vista
        -> Chiama al controller
        -> Controller Logic
        -> Il controller restituisce la vista.

Un'altra grande differenza su MVC è che la vista non si lega direttamente al modello. La vista viene semplicemente visualizzata ed è completamente apolide. Nelle implementazioni di MVC, View normalmente non avrà alcuna logica nel codice sottostante. Ciò è in contrasto con MVP dove è assolutamente necessario perché, se la vista non viene delegata al presentatore, non verrà mai chiamata.

Modello di presentazione

Un altro modello da guardare è il modello di presentazionemodello. In questo modello non c'è Presentatore. Invece la vista si lega direttamente a un modello di presentazione. Il modello di presentazione è un modello creato appositamente per la vista. Ciò significa che questo modello può esporre proprietà che non si metterebbero mai su un modello di dominio in quanto costituirebbe una violazione della separazione delle preoccupazioni. In questo caso, il modello di presentazione si lega al modello di dominio e può iscriversi agli eventi provenienti da quel modello. La vista quindi si iscrive agli eventi provenienti dal modello di presentazione e si aggiorna di conseguenza. Il modello di presentazione può esporre i comandi utilizzati dalla vista per richiamare azioni. Il vantaggio di questo approccio è che puoi essenzialmente rimuovere del tutto il code-behind poiché il PM incapsula completamente tutto il comportamento della vista.Model-View-ViewModel .

C'è un articolo MSDN sul modello di presentazione e una sezione nella Guida alle applicazioni composite per WPF (ex prisma) sui modelli di presentazione separati

— Glenn Block
fonte

27

Potete per favore chiarire questa frase? Ciò differisce da MVP in cui le azioni vengono instradate attraverso la vista al presentatore. In MVC, ogni azione nella Vista è correlata a una chiamata a un Controller insieme a un'azione. Per me sembra la stessa cosa, ma sono sicuro che stai descrivendo qualcosa di diverso.

— Panzercrisis,

16

@Panzercrisis Non sono sicuro che questo sia ciò che intendeva l'autore, ma è quello che penso stessero cercando di dire. Come questa risposta - stackoverflow.com/a/2068/74556 menziona, in MVC, i metodi del controller si basano su comportamenti - in altre parole, è possibile mappare più visualizzazioni (ma stesso comportamento) su un singolo controller. In MVP, il presentatore è accoppiato più vicino alla vista e di solito si traduce in una mappatura più vicina all'uno-a-uno, ovvero un'azione della vista è mappata al metodo del relatore corrispondente. In genere non associ le azioni di un'altra vista al metodo di un altro relatore (da un'altra vista).

— Dustin Kendall,

2

Si noti che MVC viene spesso utilizzato da framework Web come Laravel, in cui le richieste di URL ricevute (forse fatte dagli utenti) vengono gestite da Controllere l'HTML generato da Viewviene inviato al client - Quindi, Viewfa parte del backend e il l'utente non potrà mai accedervi direttamente e, se si verifica ovunque l'opposto, considerarlo come un'estensione MVC (o addirittura una violazione). @Panzercrisis, Questo differisce da MVP(come quello usato nel Androidsistema operativo) dove actions route through the View to the Presentere l'utente hanno accesso diretto al View.

— Top-Master il

455

Questa è una semplificazione eccessiva delle molte varianti di questi modelli di design, ma è così che mi piace pensare alle differenze tra i due.

MVC

MVC

MVP

inserisci qui la descrizione dell'immagine

— Phyxx
fonte

10

Questa è una grande rappresentazione dello schema, che mostra l'astrazione e l'isolamento completo di qualsiasi GUI correlato (vedi roba) dall'API del presentatore. Un punto minore: un relatore principale potrebbe essere utilizzato in presenza di un solo relatore, anziché di uno per vista, ma il diagramma è il più pulito. IMO, la più grande differenza tra MVC / MVP è che MVP cerca di mantenere la vista totalmente nulla rispetto a quella dello "stato di visualizzazione" corrente (visualizza dati), pur non consentendo alla vista di conoscere gli oggetti del Modello. Quindi le interfacce, dovendo essere lì, per iniettare quello stato.

4

Bella immagine. Uso abbastanza MVP, quindi vorrei sottolineare un punto. Nella mia esperienza, i presentatori hanno bisogno di parlarsi abbastanza spesso. Lo stesso vale per i modelli (o gli oggetti business). A causa di queste ulteriori "linee blu" di comunicazione che sarebbero presenti nella tua immagine MVP, le relazioni Presenter-Model possono diventare piuttosto intrecciate. Pertanto, tendo a mantenere una relazione One-to-Presenter-Model contro uno-a-molti. Sì, richiede alcuni metodi delegati aggiuntivi sul modello, ma riduce molti mal di testa se l'API del modello cambia o necessita di refactoring.

— splungebob,

3

L'esempio MVC è sbagliato; esiste una stretta relazione 1: 1 tra viste e controller. Per definizione, un controller interpreta l'input di gesti umani per produrre eventi per il modello e visualizzare allo stesso modo per un singolo controllo. Più semplicemente, MVC era destinato all'uso solo con singoli widget. Un widget, una vista, un controllo.

— Samuel A. Falvo II,

3

@ SamuelA.FalvoII non sempre, c'è un 1: Molti tra controllori e punti di vista in ASP.NET MVC: stackoverflow.com/questions/1673301/...

— StuperUser

4

@StuperUser - Non sono sicuro di cosa stavo pensando quando l'ho scritto. Hai ragione, ovviamente, e guardando indietro a ciò che ho scritto, devo chiedermi se avevo in mente un altro contesto che non sono riuscito a articolare. Grazie per la correzione.

— Samuel A. Falvo II,

421

Ne ho parlato un po 'di tempo fa, citando l'eccellente post di Todd Snyder sulla differenza tra i due :

Ecco le principali differenze tra i modelli:

Modello MVP

La vista è accoppiata più liberamente al modello. Il relatore è responsabile dell'associazione del modello alla vista.

Più facile da testare l'unità perché l'interazione con la vista avviene attraverso un'interfaccia

Solitamente visualizza la mappa del presentatore uno a uno. Le viste complesse possono avere più presentatori.

Motivo MVC

Il controller si basa su comportamenti e può essere condiviso tra più viste

Può essere responsabile per determinare quale vista visualizzare

È la migliore spiegazione sul web che ho trovato.

— Jon Limjap
fonte

15

Non capisco come la vista possa essere accoppiata più o meno strettamente al modello quando in entrambi i casi l'intero punto è di disaccoppiarli completamente. Non sto insinuando che tu abbia detto qualcosa di sbagliato - solo confuso su cosa intendi.

— Bill K,

18

@pst: con MVP è davvero 1 View = 1 Presenter. Con MVC, il controller può governare più viste. Questo è tutto, davvero. Con il modello "tabs" immagina che ogni tab abbia il suo Presenter invece di avere un Controller per tutte le tab.

— Jon Limjap,

4

Inizialmente ci sono due tipi di controller: quello che hai detto di essere condiviso su più viste, e quelli che sono specifici per vista, principalmente finalizzati ad adattare l'interfaccia del controller condiviso.

— Acsor,

1

@JonLimjap Cosa significa comunque una vista? Nel contesto della programmazione iOS, è uno schermo? Questo rende il controller iOS più simile a MVP che MVC? (D'altra parte puoi anche avere più controller iOS per schermo)

— huggie

2

Bene, l'illustrazione schematica di Todd di MVC contraddice completamente l'idea di disaccoppiare la vista e il modello. Se guardi il diagramma, dice Vista aggiornamenti modello (freccia da modello a vista). In quale universo è un sistema, in cui il Modello interagisce direttamente con la Vista, disaccoppiato ???

— Ash,

260

Ecco le illustrazioni che rappresentano il flusso di comunicazione

inserisci qui la descrizione dell'immagine

— Ashraf Bashir
fonte

44

Ho una domanda relativa al diagramma MVC. Non ottengo la parte in cui la vista esce per recuperare i dati. Penserei che il controller inoltrerebbe alla vista con i dati necessari.

— Brian Rizo,

54

Se un utente fa clic su un pulsante, in che modo non interagisce con la vista? Mi sento come in MVC, l'utente interagisce con la vista più che con il controller

— Jonathan

5

So che questa è una vecchia risposta, ma qualcuno potrebbe rispondere sul punto @JonathanLeaders? Vengo da uno sfondo di winforms a meno che tu non abbia fatto una codifica molto unica, quando fai clic sull'interfaccia utente / Visualizza viene a conoscenza di quel clic prima di ogni altra cosa. Almeno, per quanto ne so?

— Rob P.

6

@RobP. Penso che questi tipi di grafici tendano sempre ad essere troppo complessi o troppo semplici. Imo il flusso del grafico MVP vale anche per un'applicazione MVC. Potrebbero esserci delle variazioni, a seconda delle funzionalità delle lingue (associazione dati / osservatore), ma alla fine l'idea è di separare la vista dai dati / dalla logica dell'applicazione.

— Luca Fülbier,

15

@JonathanLeaders Le persone hanno in mente cose molto diverse quando dicono "MVC". La persona che ha creato questo grafico aveva probabilmente in mente il classico MVC Web, in cui "input dell'utente" sono richieste HTTP e "view restituito all'utente" è una pagina HTML renderizzata. Pertanto, qualsiasi interazione tra un utente e una vista "non esiste" dal punto di vista di un autore dell'app Web MVC classica.

— cubuspl42,

170

MVP non è necessariamente uno scenario in cui la vista è responsabile (vedi MVP di Taligent per esempio).
Trovo sfortunato che le persone stiano ancora predicando questo come un modello (Visualizza in carica) invece di un anti-modello in quanto contraddice "È solo una visione" (Programmatore pragmatico). "È solo una vista" afferma che la vista finale mostrata all'utente è una preoccupazione secondaria dell'applicazione. Il modello MVP di Microsoft rende il riutilizzo di Views molto più difficile e scusa convenientemente il designer di Microsoft dall'incoraggiare le cattive pratiche.

Ad essere sinceri, penso che le preoccupazioni di fondo di MVC siano vere per qualsiasi implementazione di MVP e le differenze sono quasi del tutto semantiche. Finché stai seguendo la separazione delle preoccupazioni tra la vista (che visualizza i dati), il controller (che inizializza e controlla l'interazione dell'utente) e il modello (i dati e / o servizi sottostanti), allora stai ottenendo i vantaggi di MVC . Se stai ottenendo i benefici, a chi importa davvero se il tuo modello è MVC, MVP o Supervision Controller? L'unico modello reale rimane come MVC, il resto ne ha solo diversi gusti.

Considera questo articolo estremamente interessante che elenca in modo completo una serie di queste diverse implementazioni. Si può notare che praticamente tutti fanno la stessa cosa ma in modo leggermente diverso.

Personalmente penso che MVP sia stato recentemente reintrodotto come termine accattivante per ridurre le discussioni tra bigotti semantici che sostengono se qualcosa è veramente MVC o meno o per giustificare gli strumenti di sviluppo rapido delle applicazioni di Microsoft. Nessuna di queste ragioni nei miei libri giustifica la sua esistenza come un modello di progettazione separato.

— Quibblesome
fonte

28

Ho letto diverse risposte e blog sulle differenze tra MVC / MVP / MVVM / etc '. In effetti, quando sei al lavoro, è tutto uguale. Non importa se hai un'interfaccia o meno e se stai utilizzando un setter (o qualsiasi altra funzione linguistica). Sembra che la differenza tra questi schemi sia nata dalla differenza delle implementazioni di vari framework, piuttosto che da una questione di concetto.

— Michael

6

Non chiamerei MVP un anti-pattern , come più avanti nel post "..il resto [incluso MVP] sono solo diversi sapori di [MVC] ..", il che implicherebbe che se MVP fosse un anti-pattern, quindi era MVC ... è solo un sapore per l'approccio di un framework diverso. (Ora, alcune implementazioni MVP specifiche potrebbero essere più o meno desiderabili rispetto ad alcune implementazioni MVC specifiche per compiti diversi ...)

@Quibblsome: “Personalmente penso che MVP sia stato recentemente reintrodotto solo come termine accattivante per ridurre gli argomenti tra bigotti semantici che sostengono se qualcosa sia veramente MVC o meno […] Nessuna di queste ragioni nei miei libri giustifica la sua esistenza come modello di progettazione separato. " . È abbastanza diverso da renderlo distinto. In MVP, la vista può essere qualsiasi cosa soddisfi un'interfaccia predefinita (la vista in MVP è un componente autonomo). In MVC, il Controller è concepito per una vista particolare (se le arità della relazione possono far sentire a qualcuno che vale un altro termine).

— Hibou57,

6

@ Hibou57, non c'è nulla che impedisca a MVC di fare riferimento alla vista come interfaccia o creare un controller generico per diverse viste.

— Quibblesome

1

Samuel, per favore, chiarisci di cosa stai parlando. A meno che tu non mi stia raccontando la storia del team che ha "inventato" MVC, allora sono incredibilmente dubbioso sul tuo testo. Se stai solo parlando di WinForm, allora ci sono altri modi di fare le cose e ho creato progetti WinForm in cui i controller control sono gestiti dal controller, non "controlli individuali".

— Quibblesome

110

MVP: la vista è responsabile.

La vista, nella maggior parte dei casi, crea il suo presentatore. Il relatore interagirà con il modello e manipolerà la vista attraverso un'interfaccia. La vista a volte interagirà con il presentatore, di solito attraverso qualche interfaccia. Questo si riduce all'implementazione; vuoi che la vista chiami i metodi sul presentatore o vuoi che la vista abbia eventi che il relatore ascolta? Si riduce a questo: la vista conosce il presentatore. La vista viene delegata al relatore.

MVC: il controller è responsabile.

Il controller viene creato o accessibile in base a qualche evento / richiesta. Il controller quindi crea la vista appropriata e interagisce con il modello per configurare ulteriormente la vista. Si riduce a: il controller crea e gestisce la vista; la vista è asservita al controller. La vista non è a conoscenza del controller.

— Brian Leahy
fonte

3

"La vista non è a conoscenza del controller." Penso che intendi che la vista non ha alcun contatto diretto con il modello?

— Lotus Notes,

2

vista non dovrebbe mai conoscere il modello in entrambi.

— Brian Leahy,

4

@Brian: "The View, nella maggior parte dei casi, crea il suo Presenter." . Per lo più ho visto il contrario, con il Presenter che ha lanciato sia il Modello che la Vista. Bene, anche View potrebbe lanciare il Presenter, ma quel punto non è proprio il più distintivo. Ciò che conta di più accade più tardi durante la vita.

— Hibou57,

2

Potresti voler modificare la tua risposta per spiegare ulteriormente: Dato che la vista non è a conoscenza del controller, in che modo le azioni dell'utente, che vengono eseguite sugli elementi "visivi" che l'utente vede sullo schermo (cioè la vista), vengono comunicate al controller ...

— Ash,

77

MVC (Model View Controller)

L'ingresso viene prima indirizzato al controller, non alla vista. Tale input potrebbe provenire da un utente che interagisce con una pagina, ma potrebbe anche essere semplicemente inserendo un URL specifico in un browser. In entrambi i casi, si tratta di un controller che viene interfacciato per dare il via ad alcune funzionalità. Esiste una relazione molti-a-uno tra il controller e la vista. Questo perché un singolo controller può selezionare diverse viste da rendere in base all'operazione eseguita. Nota la freccia a senso unico da Controller a Visualizza. Questo perché View non ha alcuna conoscenza o riferimento al controller. Il controller restituisce il modello, quindi esiste una conoscenza tra la vista e il modello previsto che gli viene passato, ma non il controller che lo serve.

MVP (Model View Presenter)

L'input inizia con la vista, non con il presentatore. Esiste un mapping uno a uno tra la vista e il relatore associato. La vista contiene un riferimento al presentatore. Il relatore sta inoltre reagendo agli eventi attivati dalla vista, quindi è consapevole della vista a cui è associato. Il relatore aggiorna la vista in base alle azioni richieste che esegue sul modello, ma la vista non è a conoscenza del modello.

Per ulteriori riferimenti

— AVI
fonte

Ma nel MVPmodello, quando l'applicazione viene caricata per la prima volta, il relatore non è responsabile del caricamento della prima vista? Come ad esempio quando carichiamo l'applicazione Facebook, il relatore non è responsabile del caricamento della pagina di accesso?

— vipera

2

Un collegamento dal modello alla vista in MVC? Potresti voler modificare la tua risposta per spiegare come questo lo rende un sistema "disaccoppiato", dato questo link. Suggerimento: potresti trovarlo difficile. Inoltre, a meno che tu non pensi che il lettore accetti felicemente di aver sbagliato il computer per tutta la vita, potresti voler spiegare perché le azioni passano prima attraverso il Controller in MVC nonostante l'utente interagisca con gli elementi "visivi" sullo schermo (ovvero Visualizza), non un livello astratto che sta dietro a fare l'elaborazione.

— Ash,

3

Questo è chiaramente sbagliato ... in MVC, il modello non parla mai direttamente con la vista e viceversa. Non sanno nemmeno che ne esiste un altro. Il controller è la colla che li tiene insieme

— MegaManX il

1

Sono d'accordo con Ash e MegaManX. Nel diagramma MVC, la freccia dovrebbe essere dalla vista che punta al modello (o ViewModel o DTO), non dal modello alla vista; perché il modello non è a conoscenza della vista, ma la vista potrebbe essere a conoscenza del modello.

— Jboy Flaga,

57

Ci sono molte risposte alla domanda, ma ho sentito che c'è bisogno di una risposta davvero semplice che paragona chiaramente le due cose. Ecco la discussione che ho fatto quando un utente cerca il nome di un film in un'app MVP e MVC:

Utente: fai clic fai clic ...

Visualizza : chi è quello? [ MVP | MVC ]

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

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

( Visualizza la chiamata al Presenter | Controller ...) [ MVP | MVC ]

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

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

Visualizza : Sì, eccolo ... "piano" [ 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 ]

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

Modello : Hey Presenter | Controller , fammi controllare ... [ MVP | MVC ]

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

( Dopo un po ... )

-------------- Qui è dove MVP e MVC iniziano a divergere ---------------

Modello : ho trovato un elenco per te, presentatore , eccolo in JSON “[{" name ":" Piano Teacher "," year ": 2001}, {" name ":" Piano "," year ": 1993} ] "[ 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"]. Si prega di mostrarlo all'utente in un elenco verticale. 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 ]

Visualizza : Grazie mille Presentatore [ MVP ]

Vista : grazie "Controller" [ MVC ] (Ora la Vista 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 ...? essere in un elenco verticale o orizzontale? ...)

Nel caso tu sia interessato, ho scritto una serie di articoli che trattano di modelli architetturali di app (MVC, MVP, MVVP, architettura pulita, ...) accompagnati da un repository Github qui . Anche se l'esempio è scritto per Android, i principi sottostanti possono essere applicati a qualsiasi supporto.

— Ali Nem
fonte

Fondamentalmente quello che stai cercando di dire è che il controller micromanage la logica di visualizzazione? Quindi rende la vista più stupida presentando cosa succede e come su viste?

— Radu,

@Radu, No, non micromanage, è quello che fa il presentatore rendendo la vista passiva o stupida

— Ali Nem,

4

In un MVC appropriato, la vista richiama la funzionalità sul controller e ascolta le modifiche ai dati nel modello. La vista non riceve i dati dal controller e il controller NON dovrebbe dire alla vista di visualizzare, ad esempio, un indicatore di caricamento. Un MVC corretto consente di sostituire la parte della vista, con una parte sostanzialmente diversa. La parte della vista contiene la logica della vista, che include un indicatore di caricamento. La vista richiama le istruzioni (nel controller), il controller modifica i dati nel modello e il modello notifica agli ascoltatori le modifiche ai suoi dati, uno di questi è la vista.

— Tommy Andersen,

35

MVP = Model-View-Presenter
MVC = Model-View-Controller
1. Entrambi i modelli di presentazione. Separano le dipendenze tra un modello (oggetti Think domain), la schermata / pagina Web (la vista) e il modo in cui dovrebbe comportarsi l'interfaccia utente (Presenter / Controller)
2. Sono abbastanza simili nel concetto, la gente inizializza il Presenter / Controller in modo diverso a seconda del gusto.
3. Un grande articolo sulle differenze è qui . Il più notevole è che il modello MVC ha il modello che aggiorna la vista.

— Brett Veenstra
fonte

2

Modello che aggiorna il VIew. E questo è ancora un sistema disaccoppiato?

— Ash,

34

Model-View-Controller

MVC è un modello per l'architettura di un'applicazione software. Separa la logica dell'applicazione in tre parti separate, promuovendo la modularità e la facilità di collaborazione e riutilizzo. Inoltre, rende le applicazioni più flessibili e gradevoli alle iterazioni e separa un'applicazione nei seguenti componenti:

Modelli per la gestione dei dati e della logica aziendale
Controller per la gestione dell'interfaccia utente e dell'applicazione
Viste per la gestione di oggetti dell'interfaccia utente grafica e presentazione

Per renderlo un po 'più chiaro, immaginiamo una semplice app per la lista della spesa. Tutto ciò che vogliamo è un elenco di nome, quantità e prezzo di ogni articolo che dobbiamo acquistare questa settimana. Di seguito descriveremo come potremmo implementare alcune di queste funzionalità usando MVC.

Model-View-Presenter

Il modello sono i dati che verranno visualizzati nella vista (interfaccia utente).
La vista è un'interfaccia che visualizza i dati (il modello) e instrada i comandi utente (eventi) al Presenter per agire su tali dati. La vista di solito ha un riferimento al suo Presentatore.
Il Presenter è il "intermediario" (interpretato dal controller in MVC) e ha riferimenti sia alla vista che al modello. Si noti che la parola "Modello" è fuorviante. Dovrebbe piuttosto essere la logica aziendale a recuperare o manipolare un modello . Ad esempio: se si dispone di un database che memorizza l'utente in una tabella di database e la propria vista desidera visualizzare un elenco di utenti, il presentatore avrebbe un riferimento alla logica aziendale del database (come un DAO) da cui il relatore eseguirà una query su un elenco degli utenti.

Se vuoi vedere un esempio con una semplice implementazione, controlla questo post di GitHub

Un flusso di lavoro concreto di query e visualizzazione di un elenco di utenti da un database potrebbe funzionare in questo modo:

Qual è la differenza tra i modelli MVC e MVP ?

Motivo MVC

Il controller si basa su comportamenti e può essere condiviso tra più viste
Può essere responsabile per determinare quale vista visualizzare (Pattern controller frontale)

Modello MVP

La vista è accoppiata più liberamente al modello. Il relatore è responsabile dell'associazione del modello alla vista.
Più facile da testare l'unità perché l'interazione con la vista avviene attraverso un'interfaccia
Solitamente visualizza la mappa del presentatore uno a uno. Le viste complesse possono avere più presentatori.

— Rahul
fonte

2

nah, non esiste una connessione diretta tra view e model in mvc. il tuo diagramma è sbagliato.

— Özgür,

33

Vale anche la pena ricordare che esistono anche diversi tipi di MVP. Fowler ha suddiviso il modello in due: Vista passiva e Controller di supervisione.

Quando si utilizza la vista passiva, la vista in genere implementa un'interfaccia a grana fine con proprietà che mappano più o meno direttamente al widget dell'interfaccia utente sottostante. Ad esempio, potresti avere un ICustomerView con proprietà come Nome e Indirizzo.

L'implementazione potrebbe essere simile a questa:

public class CustomerView : ICustomerView
{
    public string Name
    { 
        get { return txtName.Text; }
        set { txtName.Text = value; }
    }
}

La tua classe Presenter parlerà con il modello e lo "mapperà" alla vista. Questo approccio è chiamato "Vista passiva". Il vantaggio è che la vista è facile da testare ed è più semplice spostarsi tra le piattaforme UI (Web, Windows / XAML, ecc.). Lo svantaggio è che non puoi sfruttare cose come il databinding (che è davvero potente in framework come WPF e Silverlight ).

Il secondo aspetto di MVP è il Supervision Controller. In tal caso, la tua vista potrebbe avere una proprietà chiamata Cliente, che di nuovo è analoga ai widget UI. Non è necessario pensare alla sincronizzazione e alla micro-gestione della vista e Supervision Controller può intervenire e aiutare quando necessario, ad esempio con una logica di interazione integrata.

Il terzo "sapore" di MVP (o qualcuno lo chiamerebbe forse un modello separato) è il modello di presentazione (o talvolta riferito a Model-View-ViewModel). Rispetto all'MVP, "unisci" M e P in una classe. Hai l'oggetto cliente a cui i tuoi widget UI sono associati ai dati, ma hai anche campi specifici dell'interfaccia utente come "IsButtonEnabled", "IsReadOnly", ecc.

Penso che la miglior risorsa che ho trovato nell'architettura dell'interfaccia utente sia la serie di post sul blog pubblicati da Jeremy Miller su The Build Your Own serie CAB Sommario . Ha coperto tutti i sapori di MVP e ha mostrato il codice C # per implementarli.

Ho anche scritto un blog sul modello Model-View-ViewModel nel contesto di Silverlight su YouCard Ri-visitato: implementazione del modello ViewModel .

— Jonas Follesø
fonte

25

Ognuno di essi affronta problemi diversi e può anche essere combinato per avere qualcosa di simile al di sotto

Il modello combinato

C'è anche un confronto completo di MVC, MVP e MVVM qui

— Xiaoguo Ge
fonte

1

Invece di complicare troppo le cose, avresti potuto rispondere alla domanda. Ecco perché la maggior parte di noi è qui. Ho cercato il confronto tra mvp e mvc e sono stato reindirizzato qui e stai parlando dell'armonia di quelle architetture non correlate a OP.

— Farid,

18

Entrambi questi framework mirano a preoccupazioni separate, ad esempio l'interazione con un'origine dati (modello), la logica dell'applicazione (o la trasformazione di questi dati in informazioni utili) (Controller / Presentatore) e il codice di visualizzazione (Visualizza). In alcuni casi il modello può anche essere utilizzato per trasformare un'origine dati in un'astrazione di livello superiore. Un buon esempio di ciò è il progetto Storefront MVC .

C'è una discussione qui per quanto riguarda le differenze tra MVC vs MVP.

La distinzione fatta è che in un'applicazione MVC tradizionalmente la vista e il controller interagiscono con il modello, ma non tra loro.

I progetti MVP consentono al Presenter di accedere al modello e interagire con la vista.

Detto questo, ASP.NET MVC è in base a queste definizioni un framework MVP perché il Controller accede al Modello per popolare la Vista che non ha alcuna logica (visualizza solo le variabili fornite dal Controller).

Per avere un'idea della distinzione ASP.NET MVC da MVP, dai un'occhiata a questa presentazione MIX di Scott Hanselman.

— Matt Mitchell
fonte

7

MVC e MVP sono schemi, non quadri. Se pensi onestamente, quell'argomento riguardava .NET framework, quindi è come ascoltare "Internet" e pensare che si tratti di IE.

— tereško,

Abbastanza sicuro che la domanda si sia evoluta in modo significativo da quando è stata posta per la prima volta nel 2008. Inoltre, guardando indietro alla mia risposta (e questo è stato 4 anni fa, quindi non ho molto più contesto di te) direi che inizio in generale e quindi utilizzare .NET MVC come esempio concreto.

— Matt Mitchell,

13

Entrambi sono modelli che cercano di separare la presentazione e la logica aziendale, disaccoppiando la logica aziendale dagli aspetti dell'interfaccia utente

Dal punto di vista architettonico, MVP è un approccio basato su Page Controller in cui MVC è un approccio basato su Front Controller. Ciò significa che nel ciclo di vita della pagina web dei moduli Web standard MVP è stato semplicemente migliorato estraendo la logica aziendale dal codice sottostante. In altre parole, la pagina è quella che serve la richiesta http. In altre parole, MVP IMHO è un tipo di miglioramento evolutivo del modulo web. MVC invece cambia completamente il gioco perché la richiesta viene intercettata dalla classe del controller prima che la pagina venga caricata, la logica aziendale viene eseguita lì e quindi al risultato finale del controller che elabora i dati appena scaricati nella pagina ("view") senso, MVC guarda (almeno per me) molto al sapore Supervision Controller MVP migliorato con il motore di routing

Entrambi abilitano TDD e hanno aspetti negativi e positivi.

La decisione su come scegliere uno di questi IMHO dovrebbe essere basata su quanto tempo si è investito nel tipo di sviluppo web del modulo Web ASP NET. Se uno si considerasse bravo nei moduli web, suggerirei MVP. Se non ci si sente a proprio agio in cose come il ciclo di vita della pagina ecc. MVC potrebbe essere un modo per andare qui.

Ecco ancora un altro link al post del blog che fornisce alcuni dettagli in più su questo argomento

http://blog.vuscode.com/malovicn/archive/2007/12/18/model-view-presenter-mvp-vs-model-view-controller-mvc.aspx

— Nikola Malovic
fonte

9

Ho usato sia MVP che MVC e sebbene noi come sviluppatori tendiamo a concentrarci sulle differenze tecniche di entrambi i modelli, il punto per MVP in IMHO è molto più legato alla facilità di adozione di ogni altra cosa.

Se sto lavorando in un team che già come buon background sullo stile di sviluppo dei moduli web è molto più facile introdurre MVP che MVC. Direi che MVP in questo scenario è una vittoria veloce.

La mia esperienza mi dice che spostare un team dai moduli Web a MVP e quindi da MVP a MVC è relativamente semplice; passare dai moduli Web a MVC è più difficile.

Lascio qui un link ad una serie di articoli che un mio amico ha pubblicato su MVP e MVC.

http://www.qsoft.be/post/Building-the-MVP-StoreFront-Gutthrie-style.aspx

— Pedro Santos
fonte

8

In MVP la vista estrae i dati dal presentatore che disegna e prepara / normalizza i dati dal modello mentre in MVC il controller estrae i dati dal modello e li imposta, premendo nella vista.

In MVP puoi avere un'unica vista che funziona con più tipi di presentatori e un singolo relatore che lavora con diverse viste multiple.

MVP di solito utilizza una sorta di framework di associazione, come Microsoft WPF Framework o vari framework di associazione per HTML5 e Java.

In tali framework, l'interfaccia utente / HTML5 / XAML è a conoscenza di quale proprietà del presentatore viene visualizzata da ciascun elemento dell'interfaccia utente, quindi quando si associa una vista a un presentatore, la vista cerca le proprietà e sa come trarre dati da esse e come per impostarli quando un valore viene modificato nell'interfaccia utente dall'utente.

Quindi, se per esempio, il modello è un'auto, allora il presentatore è una specie di presentatore di auto, espone le proprietà dell'auto (anno, produttore, sedili, ecc.) Alla vista. La vista sa che il campo di testo chiamato "produttore di auto" deve visualizzare la proprietà Maker del presentatore.

Puoi quindi associare alla vista molti diversi tipi di presentatore, tutti devono avere la proprietà Maker - può essere di un aereo, treno o qualsiasi altra cosa, alla vista non importa. La vista trae i dati dal presentatore - indipendentemente da quale - purché implementi un'interfaccia concordata.

Questo framework vincolante, se lo rimuovi, è in realtà il controller :-)

E così, puoi considerare MVP come un'evoluzione di MVC.

MVC è eccezionale, ma il problema è che di solito il suo controller per vista. Il controller A sa come impostare i campi della vista A. Se ora si desidera che la vista A mostri i dati del modello B, è necessario il controller A per conoscere il modello B oppure il controller A per ricevere un oggetto con un'interfaccia, che è come MVP solo senza i binding, oppure è necessario riscrivere il codice del set di UI nel controller B.

Conclusione: MVP e MVC sono entrambi disaccoppiati dei modelli di interfaccia utente, ma MVP di solito utilizza un framework di binding che è MVC al di sotto. THUS MVP ha un livello architettonico superiore rispetto a MVC e un modello wrapper sopra MVC.

— James Roeiter
fonte

6

La mia umile visione breve: MVP è per le grandi scale e MVC per le piccole scale. Con MVC, a volte sento che V e C possono essere visti i due lati di un singolo componente indivisibile piuttosto legato direttamente a M, e uno inevitabilmente cade su questo quando si scende a scale più brevi, come i controlli dell'interfaccia utente e i widget di base. A questo livello di granularità, MVP ha poco senso. Quando uno va al contrario su scale più grandi, l'interfaccia corretta diventa più importante, lo stesso con l'assegnazione inequivocabile delle responsabilità, e qui arriva MVP.

D'altra parte, questa regola di scala di un pollice, può pesare molto poco quando le caratteristiche della piattaforma favoriscono un qualche tipo di relazione tra i componenti, come con il web, dove sembra essere più facile implementare MVC, più che MVP.

— Hibou57
fonte

4

Penso che questa immagine di Erwin Vandervalk (e l' articolo di accompagnamento ) sia la migliore spiegazione di MVC, MVP e MVVM, delle loro somiglianze e delle loro differenze. L' articolo non viene visualizzato nei risultati del motore di ricerca per query su "MVC, MVP e MVVM" perché il titolo dell'articolo non contiene le parole "MVC" e "MVP"; ma è la migliore spiegazione, penso.

immagine che spiega MVC, MVP e MVVM - di Erwin Vandervalk

(L' articolo corrisponde anche a ciò che ha detto lo zio Bob Martin nel suo discorso: che MVC era stato originariamente progettato per i piccoli componenti dell'interfaccia utente, non per l'architettura del sistema)

— Jboy Flaga
fonte

3

Esistono molte versioni di MVC, questa risposta riguarda l'originale MVC in Smalltalk. In breve, lo è

Questo talk droidcon NYC 2017 - Il design pulito dell'app con Architecture Components lo chiarisce

— onmyway133
fonte

6

Nel MVC il Modello non viene mai chiamato direttamente dalla vista

— rodi,

5

Questa è una risposta inaccurata. Non essere fuorviato. come scrive @rodi, non c'è interazione tra View e Model.

— Shawn Mehan,

L'immagine MVC è inaccurata o nella migliore delle ipotesi fuorviante, si prega di non prestare attenzione a questa risposta.

— Jay,

2

@ Jay1b Quale MVC pensi sia "corretto"? Questa risposta riguarda l'MVC originale. Ci sono molti altri MVC (come in iOS) che sono stati modificati per adattarsi alla piattaforma, ad esempioUIKit

— onmyway133

Cosa significano le frecce?

— problemofficer,

3

C'è questo bel video di Zio Bob in cui spiega brevemente MVC e MVP alla fine.

IMO, MVP è una versione migliorata di MVC in cui fondamentalmente separa la preoccupazione di ciò che mostrerai (i dati) da come mostrerai (la vista). Il presentatore include in qualche modo la logica aziendale dell'interfaccia utente, impone implicitamente quali dati devono essere presentati e fornisce un elenco di modelli di vista stupidi. E quando arriva il momento di mostrare i dati, è sufficiente collegare la vista (probabilmente include gli stessi ID) nell'adattatore e impostare i campi di vista pertinenti utilizzando quei modelli di vista con una quantità minima di codice introdotta (solo utilizzando setter). Il suo principale vantaggio è che puoi testare la tua logica di business dell'interfaccia utente rispetto a molte / varie viste come la visualizzazione di elementi in un elenco orizzontale o verticale.

In MVC, parliamo attraverso interfacce (confini) per incollare diversi strati. Un controller è un plug-in per la nostra architettura ma non ha una tale limitazione per imporre cosa mostrare. In tal senso, MVP è una specie di MVC con un concetto di viste collegabile al controller tramite adattatori.

Spero che questo aiuti meglio.

— stdout
fonte

2

Punto importante di zio Bob: quando originariamente inventato da Trygve Reenskaug, MVC era pensato per ogni widget e non per l'intero modulo.

— Basil Bourque,

2

Hai dimenticato Action-Domain-Responder ( ADR ).

Come spiegato in alcuni grafici sopra, esiste un rapporto / collegamento diretto tra il Modello e la Vista in MVC. Viene eseguita un'azione sul controller , che eseguirà un'azione sul modello . Quell'azione nel Modello , attiverà una reazione nella Vista . La vista viene sempre aggiornata quando cambia lo stato del modello .

Alcune persone continuano a dimenticare che MVC è stato creato alla fine degli anni 70 " e che il Web è stato creato solo alla fine degli 80" / inizio 90 ". MVC non era originariamente creato per il Web, ma per le applicazioni desktop, dove il controller , Model and View coesisteranno insieme.

Poiché utilizziamo framework Web ( ad esempio: Laravel ) che usano ancora le stesse convenzioni di denominazione ( model-view-controller ), tendiamo a pensare che debba essere MVC, ma in realtà è qualcos'altro.

Invece, dai un'occhiata a Action-Domain-Responder . In ADR, il Controller ottiene un'azione che eseguirà un'operazione nel Modello / Dominio . Finora lo stesso. La differenza è che raccoglie quindi la risposta / i dati di quell'operazione e li passa a un risponditore ( ad esempio :.view() ) per il rendering. Quando viene richiesta una nuova azione sullo stesso componente, il controller viene richiamato nuovamente e il ciclo si ripete. In ADR, non esiste alcuna connessione tra il Modello / Dominio e la Vista ( risposta di Reponser ).

Nota: Wikipedia afferma che " Ogni azione ADR, tuttavia, è rappresentata da classi o chiusure separate ". Questo non lo è necessariamente vero. Diverse azioni possono essere nello stesso controller e il modello è sempre lo stesso.

mvc adr model-view-controller action-domain-responder

— Hugo Rafael Azevedo
fonte

2

La risposta più semplice è come la vista interagisce con il modello. In MVP la vista viene aggiornata dal presentatore, che funge da intermediario tra la vista e il modello. Il relatore accetta l'input dalla vista, che recupera i dati dal modello, quindi esegue qualsiasi logica aziendale richiesta e quindi aggiorna la vista. In MVC il modello aggiorna la vista direttamente anziché tornare indietro attraverso il controller.

— Clive Jefferies
fonte

Ho effettuato il downgrade, perché afaik il modello non sa nulla della vista in MVC e non è possibile aggiornarlo direttamente durante la scrittura.

— problemofficer,

1

Guarda MVC su Wikipedia, è esattamente così che funziona.

— Clive Jefferies,

1

Che piaccia o meno ai lettori, molte fonti che possono essere trovate da Google affermano che in MVC la vista si abbona agli aggiornamenti sul modello. e in alcuni casi potrebbe persino essere il controller e quindi invocare tali aggiornamenti. Se non ti piace, allora vai a lamentarti di quegli articoli o cita quale "bibbia" ritieni sia l'unica fonte legittima, invece di effettuare il downgrade delle risposte che trasmettono semplicemente le altre informazioni disponibili là fuori!

— underscore_d

1

La formulazione potrebbe sicuramente essere migliorata, ma è vero che la vista si abbona alle modifiche del modello in MVC. Non è necessario che il modello conosca la vista in MVC.

— divorò elisio il

grazie ... Mi ha aiutato molto

— Dvyn Resh,

1

In MVC, View ha la parte UI, il controller è il mediatore tra view e modello e modello contiene la logica aziendale.
In MVP, View contiene sia l'interfaccia utente che l'implementazione del presentatore poiché qui il presentatore è solo un'interfaccia e il modello è lo stesso, ovvero contiene la logica aziendale.

— Chinmai Kulkarni
fonte

-1

MVP

MVP sta per Model - View- Presenter. Questo è arrivato a un quadro all'inizio del 2007 in cui Microsoft ha introdotto le applicazioni Windows Smart Client.

Un relatore agisce come un ruolo di supervisione in MVP che lega gli eventi Visualizza e la logica aziendale dai modelli.

Il binding dell'evento di visualizzazione verrà implementato nel Presenter da un'interfaccia di visualizzazione.

La vista è l'iniziatore degli input dell'utente, quindi delega gli eventi al Presenter e il presentatore gestisce i binding degli eventi e ottiene i dati dai modelli.

Professionisti: la vista ha solo un'interfaccia utente senza logiche. Livello di testabilità elevato

Contro: Bit complessi e più lavoro durante l'implementazione di associazioni di eventi

MVC

MVC sta per Model-View-Controller. Il controller è responsabile della creazione di modelli e del rendering delle viste con modelli vincolanti.

Il controller è l'iniziatore e decide quale vista visualizzare.

Pro: enfasi sul principio di responsabilità singola Alto livello di testabilità

Contro: a volte un carico di lavoro eccessivo per i controller, se si tenta di eseguire il rendering di più viste nello stesso controller.

— marvelTracker
fonte