Domanda Cosa sono MVP e MVC e qual è la differenza?


Quando si guarda oltre il RAD (drag-drop e configura) il modo di costruire interfacce utente che molti strumenti ti incoraggiano a trovare tre modelli di design chiamati Model-View-Controller, Model-View-Presenter e Model-View-ViewModel. La mia domanda ha tre parti:

  1. Quali problemi affrontano questi schemi?
  2. Come sono simili?
  3. Come sono differenti?

1834
2017-08-05 10:06


origine


risposte:


Model-View-Presenter

In MVP, il Presenter contiene la logica di business dell'interfaccia utente per la vista. Tutte le chiamate dalla vista possono essere delegate direttamente a Presenter. Anche il Presenter viene disaccoppiato direttamente dalla vista e comunica attraverso un'interfaccia. Questo è per consentire il mocking della vista in un test unitario. Un attributo comune di MVP è che ci deve essere un sacco di dispacciamento a due vie. Ad esempio, quando qualcuno fa clic sul pulsante "Salva", il gestore eventi delega il metodo "OnSave" del relatore. Una volta completato il salvataggio, Presenter richiamerà la vista attraverso la sua interfaccia in modo che la vista possa mostrare 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 scopri di più su entrambe le varianti.

Due variazioni primarie

Vista passiva: La vista è il più stupida possibile e contiene una logica quasi zero. Il presentatore è un intermediario che parla alla vista e al modello. La vista e il modello sono completamente schermati l'uno dall'altro. Il Modello può generare eventi, ma il Presentatore li sottoscrive per l'aggiornamento della Vista. In Passive View non esiste un binding diretto dei dati, invece la View espone le proprietà setter che il Presenter usa 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 stai facendo tutti i dati vincolanti.

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

  • Pro: sfruttando il database si riduce la quantità di codice.
  • Contro: c'è meno superficie testabile (a causa del binding dei dati), e c'è meno incapsulamento nella Vista poiché parla direttamente al Modello.

Model-View-Controller

Nel MVC, il Controller è responsabile della determinazione della Vista da visualizzare in risposta a qualsiasi azione, compresa la carica dell'applicazione. Questo differisce da MVP in cui le azioni passano 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
        -> Logica controller
        -> Controller restituisce la vista.

Un'altra grande differenza su MVC è che la vista non si lega direttamente al modello. La vista semplicemente rende ed è completamente apolidi. Nelle implementazioni di MVC, la vista di solito non avrà alcuna logica nel codice sottostante. Questo è contrario a MVP dove è assolutamente necessario perché, se la Vista non delegherà al Presentatore, non verrà mai chiamato.

Modello di presentazione

Un altro modello da guardare è il Modello di presentazione modello. In questo modello non c'è Presenter. 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 sarebbe una violazione della separazione delle preoccupazioni. In questo caso, il modello di presentazione si collega al modello di dominio e può sottoscrivere eventi provenienti da quel modello. La vista quindi si abbona agli eventi provenienti dal modello di presentazione e si aggiorna di conseguenza. Il modello di presentazione può esporre comandi che la vista usa per invocare azioni. Il vantaggio di questo approccio è che è possibile rimuovere completamente il code-behind poiché il PM incapsula completamente tutto il comportamento per la vista. Questo modello è un candidato molto valido per l'uso nelle applicazioni WPF e viene anche chiamato Model-View-ViewModel.

C'è un Articolo MSDN sul modello di presentazione e una sezione nel Guida all'applicazione composita per WPF (ex Prism) circa Modelli di presentazione separati


1796
2017-08-05 10:21



Ho parlato di questo poco fa, citando L'eccellente post di Todd Snyder sulla differenza tra i due:

Ecco le principali differenze tra   i modelli:

Pattern MVP

  • La vista è più liberamente accoppiata al modello. Il presentatore è   responsabile per l'associazione del modello a   la vista.
  • Test dell'unità più semplice perché l'interazione con la vista è passata   un'interfaccia
  • Di solito visualizza la mappa del relatore una a una. Possono avere viste complesse   multi presentatori.

Pattern MVC

  • I controller sono basati su comportamenti e possono essere condivisi   visualizzazioni
  • Può essere responsabile per determinare quale vista visualizzare

È la migliore spiegazione sul web che ho trovato.


384
2017-07-06 22:18



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

enter image description here


367
2017-09-12 20:47



Ecco le illustrazioni che rappresentano il flusso di comunicazione

enter image description here 

enter image description here


208
2017-08-25 21:22



MVP è non necessariamente uno scenario in cui la vista è in carica (vedi MVP di Taligent per esempio).
Trovo sfortunato che le persone stiano ancora predicando questo come uno schema (View in charge) in contrapposizione a un anti-pattern in quanto contraddice "It's just a view" (Pragmatic Programmer). "È solo una vista" afferma che la vista finale mostrata all'utente è una preoccupazione secondaria dell'applicazione. Il pattern MVP di Microsoft rende il riutilizzo delle Views molto più difficile e opportunamente scusa il designer di Microsoft dall'incoraggiare le cattive pratiche.

Per essere sinceri, penso che le preoccupazioni di fondo di MVC siano valide per qualsiasi implementazione di MVP e le differenze sono quasi del tutto semantiche. Finché segui 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 / oi servizi sottostanti)), allora stai beneficiando dei vantaggi di MVC . Se stai ottenendo i benefici, allora a chi importa davvero se il tuo pattern è MVC, MVP o Supervising Controller? Il solo vero il pattern rimane come MVC, il resto sono solo diversi sapori di esso.

Prendere in considerazione Questo articolo molto eccitante che elenca in modo completo un certo numero di queste diverse implementazioni. Potresti notare che fondamentalmente stanno facendo la stessa cosa, ma in modo leggermente diverso.

Personalmente ritengo che MVP sia stato recentemente reintrodotto come termine accattivante per ridurre gli argomenti tra bigotti semantici che discutono se qualcosa sia veramente MVC o no o per giustificare gli strumenti di sviluppo rapido di Microsofts. Nessuna di queste ragioni nei miei libri giustifica la sua esistenza come modello di progetto separato.


148
2017-08-06 22:51



MVP: la vista è in carica.

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 interagisce con il presentatore, di solito attraverso alcune interfacce. Questo dipende dall'implementazione; vuoi che la vista chiami i metodi sul presentatore o vuoi che la vista abbia degli eventi che il presentatore ascolta? Si riduce a questo: la vista è a conoscenza del presentatore. La vista delega al presentatore.

MVC: il controller è in carica.

Il controller viene creato o consultato in base ad alcuni eventi / richieste. Il controller crea quindi 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 è schiava del controller. La vista non conosce il controller.


90
2017-12-20 02:10



enter image description here

MVC (Model View Controller)

L'input è diretto prima al Controller, non alla vista. Tale input potrebbe provenire da un utente che interagisce con una pagina, ma potrebbe anche essere semplicemente inserire un URL specifico in un browser. In entrambi i casi, è un controller a cui è possibile interfacciare 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 visualizzazioni da rendere in base all'operazione che viene eseguita. Notare la freccia a senso unico da Controller a Vista. Questo perché la vista non ha alcuna conoscenza o riferimento al controller. Il Controller rinvia il Modello, quindi è presente la conoscenza tra la Visualizzazione e il Modello previsto, ma non il Controller che lo serve.

MVP (Model View Presenter)

L'input inizia con View, non con Presenter. Esiste una mappatura uno-a-uno tra la vista e il relatore associato. La vista contiene un riferimento al presentatore. Anche Presenter reagisce agli eventi attivati ​​dalla vista, quindi è a conoscenza 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 più Riferimento


62
2017-08-05 10:22



  • MVP = Model-View-Presenter
  • MVC = Model-View-Controller

    1. Entrambi i modelli di presentazione. Separano le dipendenze tra un modello (pensate agli oggetti Dominio), lo schermo / pagina web (la vista) e il comportamento dell'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.

31
2017-08-08 05:55



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 Vista passiva, la vista in genere implementa un'interfaccia a grana fine con la mappatura delle proprietà più o meno direttamente al widget dell'interfaccia utente sottostante. Ad esempio, potresti avere un ICustomerView con proprietà come Nome e Indirizzo.

La tua 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ù facile spostarsi tra le piattaforme dell'interfaccia utente (Web, Windows / XAML, ecc.). Lo svantaggio è che non è possibile sfruttare le cose come il databinding (che è veramente potente in quadri come WPF e Silverlight).

Il secondo gusto di MVP è il supervisore supervisore. In tal caso, la tua Vista potrebbe avere una proprietà chiamata Cliente, che quindi è di nuovo legata ai widget dell'interfaccia utente. Non è necessario pensare alla sincronizzazione e alla microgestione della vista e il Supervising Controller può intervenire e aiutare quando necessario, ad esempio con la logica di interazione integrata.

Il terzo "sapore" di MVP (o qualcuno potrebbe chiamarlo un modello separato) è il modello di presentazione (o talvolta riferito a Model-View-ViewModel). Rispetto al MVP si "unire" il M e il P in una classe. Hai il tuo oggetto cliente a cui i tuoi widget UI sono associati, ma hai anche campi di spionaggio dell'interfaccia utente come "IsButtonEnabled" o "IsReadOnly", ecc.

Penso che la migliore risorsa che ho trovato per l'architettura dell'interfaccia utente sia la serie di post sul blog di Jeremy Miller Il sommario della serie CAB Build Your Own. Ha coperto tutti i sapori di MVP e ha mostrato il codice C # per implementarli.

Ho anche eseguito il blogging sul pattern Model-View-ViewModel nel contesto di Silverlight Rivisitazione di YouCard: implementazione del modello ViewModel.


31
2018-04-06 13:51



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

Utente: clicca clic ...

vista: Chi è quello? [MVP|MVC]

Utente: ho appena cliccato sul pulsante di ricerca ...

vista: Ok, aspetta un attimo ... [MVP|MVC]

( vista chiamando il Presentatore|controllore ...) [MVP|MVC]

vista: Hey Presentatore|controllore, un utente ha appena cliccato sul pulsante di ricerca, cosa devo fare? [MVP|MVC]

Presentatore|controllore: Hey vista, c'è qualche termine di ricerca in quella pagina? [MVP|MVC]

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

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

( Presentatore|controllore sta chiamando il Modello ...) [MVP|MVC]

Presentatore|controllore: Hey Modello, Hai una corrispondenza per questo termine di ricerca ?: "piano" [MVP|MVC]

Modello: Hey Presentatore|controllore, fammi controllare … [MVP|MVC]

( Modello sta facendo una query al database del film ...) [MVP|MVC]

( Dopo un po ... )

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

Modello: Ho trovato una lista per te Presentatore, eccolo in JSON "[{" name ":" Piano Teacher "," year ": 2001}, {" name ":" Piano "," year ": 1993}]" [MVP]

Modello: C'è qualche risultato disponibile, controllore. Ho creato una variabile di campo nella mia istanza e l'ho riempita con il risultato. Il suo nome è "searchResultsList" [MVC]

(Presentatore|controllore Grazie Modello e torna al vista) [MVP|MVC]

Presentatore: Grazie per aver aspettato vistaHo trovato un elenco di risultati corrispondenti per te e li ho disposti in un formato presentabile: ["Piano Teacher 2001", "Piano 1993"]. Si prega di mostrarlo all'utente in una lista verticale. Inoltre ti preghiamo di nascondere la barra di avanzamento ora [MVP]

controllore: Grazie per aver aspettato vista, Ho chiesto Modello sulla 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 ti preghiamo di nascondere la barra di avanzamento ora [MVC]

vista: Grazie mille Presentatore [MVP]

vista: Grazie "Controller" [MVC] (Ora il vista si sta interrogando: come dovrei presentare i risultati che ottengo dal Modello per l'utente? L'anno di produzione del film dovrebbe essere il primo o l'ultimo ...? Dovrebbe essere in una lista verticale o orizzontale? ...)

Nel caso tu sia interessato, ho scritto una serie di articoli che trattano modelli di app (MVC, MVP, MVVP, architettura pulita, ...) accompagnati da un repository Github Qui. Anche se il campione è scritto per Android, i principi di base possono essere applicati a qualsiasi mezzo.


17
2017-08-05 10:20