Cosa sono MVP e MVC e qual è la differenza?

Guardando oltre il modo RAD (drag-drop e configura) di build interfacce utente che molti strumenti incoraggiano, è probabile che si incontrino 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?

Model-View-Presenter

In MVP , 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 saperne di più su entrambe le varianti .

Due variazioni primarie

Vista passiva: la vista è il più stupida ansible e contiene quasi zero logica. 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.

Controller di supervisione: 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

In 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 considerare è il modello del modello di presentazione. 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 è ansible 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 ed è anche chiamato Model-View-ViewModel .

C’è un articolo di MSDN sul modello di presentazione e una sezione nell’indicazione per le applicazioni composite per WPF (ex Prisma) sui modelli di presentazione separati

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:

Pattern MVP

  • La vista è più liberamente accoppiata al modello. Il relatore è responsabile per l’associazione del modello alla vista.
  • Test dell’unità più semplice perché l’interazione con la vista avviene tramite un’interfaccia
  • Di solito visualizza la mappa del relatore una a una. Le viste complesse possono avere più presentatori.

Pattern MVC

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

È la migliore spiegazione sul web che ho trovato.

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 la descrizione dell'immagine qui

Ecco le illustrazioni che rappresentano il stream di comunicazione

inserisci la descrizione dell'immagine qui

inserisci la descrizione dell'immagine qui

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 scusa convenientemente 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? L’unico modello reale rimane come MVC, il resto sono solo diversi sapori di esso.

Considera questo articolo estremamente interessante 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 acctriggersnte 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.

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.

inserisci la descrizione dell'immagine qui

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 è ansible 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 mapping uno-a-uno tra la vista e il relatore associato. La vista contiene un riferimento al presentatore. Anche Presenter reagisce agli eventi triggersti ​​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 ulteriori riferimenti

  • 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.

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 mapping 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 class 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 piattaforms dell’interfaccia utente (Web, Windows / XAML, ecc.). Lo svantaggio è che non è ansible sfruttare elementi come il databinding (che è molto potente in framework 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 class. Hai il tuo object 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 su Sommario Build Your Own CAB Series . 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 su YouCard Rivisitato: implementazione del pattern ViewModel .

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 …

Visualizza : chi è quello? [ MVP | MVC ]

Utente: ho appena cliccato sul pulsante di ricerca …

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

( Vedi a chiamare il presentatore | Controller …) [ MVP | MVC ]

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

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

Visualizza : Sì, … eccolo … “piano” [ MVP | MVC ]

Presenter : Thanks View , … nel frattempo sto cercando il termine di ricerca sul modello , per favore mostragli una barra di avanzamento [ MVP | MVC ]

( Presentatore | Controller sta chiamando il Modello …) [ MVP | MVC ]

Presentatore | Controller : modello Hey, hai una corrispondenza per questo termine di ricerca ?: “piano” [ MVP | MVC ]

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

(Il 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, Presenter , qui è in JSON “[{” name “:” Piano Teacher “,” year “: 2001}, {” name “:” Piano “,” year “: 1993} ] “[ MVP ]

Modello : sono disponibili alcuni 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 il modello e torna alla vista ) [ MVP | MVC ]

Presentatore : Grazie per l’attesa View , ho trovato per te un elenco di risultati corrispondenti 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 hide la barra di avanzamento ora [ MVP ]

Controller : Grazie per l’attesa View , ho chiesto a Model 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 hide la barra di avanzamento ora [ MVC ]

Visualizza : Grazie mille Presenter [ MVP ]

Visualizza : Grazie “Controller” [ MVC ] (Ora la vista si sta interrogando da sola: come dovrei presentare i risultati che ottengo dal modello all’utente? Dovrebbe l’anno di produzione del film arrivare prima o l’ultimo …? 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 repo Github qui . Anche se il campione è scritto per Android, i principi di base possono essere applicati a qualsiasi mezzo.

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

C’è una discussione qui riguardo 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 l’uno con l’altro.

I modelli MVP hanno il Presenter per accedere al modello e interagire con la vista.

Detto questo, ASP.NET MVC è definito da queste definizioni come un framework MVP poiché 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, controlla questa presentazione MIX di Scott Hanselman.

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

Il modello combinato

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

Entrambi sono schemi che cercano di separare la presentazione e la logica aziendale, separando la logica di business dagli aspetti dell’interfaccia utente

Architettonicamente, MVP è un approccio basato su Controller di pagina in cui MVC è un approccio basato su Front Controller. Ciò significa che nel ciclo di vita del modulo Web standard MVP viene 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 del modulo web evolutivo. MVC sull’altra mano cambia completamente il gioco perché la richiesta viene intercettata dalla class 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 sulla pagina (“view”) In quella senso, MVC sembra (almeno per me) molto al sapore Supervisore del controller di MVP migliorato con il motore di routing

Entrambi consentono il TDD e hanno aspetti negativi e positivi.

Decisione su come scegliere uno di loro IMHO dovrebbe essere basato su quanto tempo uno ha investito in tipo di web form ASP NET di sviluppo web. Se uno si considera buono nei moduli web, suggerirei MVP. Se uno non si sentisse a suo agio in cose come il ciclo di vita della pagina, ecc. MVC potrebbe essere un modo per andare qui.

Ecco un altro link al post sul blog che fornisce alcuni dettagli su questo argomento

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

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. Rende anche le applicazioni più flessibili e accoglienti per le iterazioni. Separa un’applicazione nei seguenti componenti:

  • Modelli per la gestione di dati e logica aziendale
  • Controller per la gestione dell’interfaccia utente e dell’applicazione
  • Visualizzazioni per la gestione di oggetti e presentazioni dell’interfaccia utente grafica

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

inserisci la descrizione dell'immagine qui

Model-View-Presenter

  • Il modello è i dati che verranno visualizzati nella vista (interfaccia utente).
  • La vista è un’interfaccia che visualizza i dati (il modello) e instrada i comandi dell’utente (eventi) al Presenter per agire su tali dati. Di solito la vista ha un riferimento al suo Presenter.
  • The Presenter è il “middle man” (interpretato dal controller in MVC) e ha riferimenti a entrambi, vista e modello. Si prega di notare che la parola “Modello” è fuorviante. Dovrebbe piuttosto essere la logica aziendale che recupera o manipola un modello . Ad esempio: se si dispone di un database che archivia Utente in una tabella di database e la propria Vista desidera visualizzare un elenco di utenti, il Presenter avrà un riferimento alla logica aziendale del database (come un DAO) da cui il Presenter interrogherà un elenco di utenti.

Se vuoi vedere un esempio con un’implementazione semplice, controlla questo post github

Un stream di lavoro concreto di interrogazione e visualizzazione di un elenco di utenti da un database potrebbe funzionare in questo modo: inserisci la descrizione dell'immagine qui

Qual è la differenza tra i modelli MVC e MVP ?

Pattern MVC

  • I controller sono basati sui comportamenti e possono essere condivisi tra le visualizzazioni

  • Può essere responsabile della determinazione della vista da visualizzare (Pattern controller anteriore)

Pattern MVP

  • La vista è più liberamente accoppiata al modello. Il relatore è responsabile per l’associazione del modello alla vista.

  • Test dell’unità più semplice perché l’interazione con la vista avviene tramite un’interfaccia

  • Di solito visualizza la mappa del relatore una a una. Le viste complesse possono avere più presentatori.

Qualcosa che non capisco è perché l’associazione dei dati debba ridurre la testabilità. Voglio dire, una vista è efficacemente basata su ciò che si potrebbe pensare come una o più viste del database, giusto? Potrebbero esserci connessioni tra righe in diverse viste. In alternativa, possiamo parlare di orientamento agli oggetti anziché relazionale, ma in realtà non cambia nulla: abbiamo ancora una o più entity framework di dati distinte.

Se consideriamo la programmazione come strutture di dati + algoritmi, allora non sarebbe meglio avere le strutture dati rese più esplicite possibili, e quindi sviluppare algoritmi che dipendono ciascuno da un numero di dati il ​​più piccolo ansible, con un accoppiamento minimo tra gli algoritmi ?

Percepisco qui molto i modelli di pensiero FactoryFactoryFactory di Java-esque: vogliamo avere più viste, più modelli, più gradi di libertà ovunque. È quasi come se fosse la forza trainante di MVC e MVP e quant’altro. Ora lascia che ti chieda: quanto spesso vale il costo che paghi per questo (e c’è sicuramente un costo)?

Non vedo inoltre alcuna discussione su come gestire in modo efficiente lo stato tra richieste HTTP. Non abbiamo imparato dalla gente funzionale (e dai voluminosi errori fatti dagli spaghetti imperiosi) che lo stato è malvagio e dovrebbe essere minimizzato (e se usato, dovrebbe essere ben compreso)?

Vedo un sacco di utilizzo dei termini MVC e MVP senza molte prove che la gente pensa in modo critico su di loro. Chiaramente, il problema è “loro”, io o entrambi …

In Android c’è la versione di mvc che è mvp: che cos’è MVP?

Il pattern MVP consente di separare il livello di presentazione dalla logica, in modo che tutto ciò che riguarda il funzionamento dell’interfaccia sia separato da come lo rappresentiamo sullo schermo. Idealmente, lo schema MVP otterrebbe la stessa logica e potrebbe avere viste completamente diverse e intercambiabili.

La prima cosa da chiarire è che MVP non è un modello architettonico, è solo responsabile del livello di presentazione. In ogni caso è sempre meglio usarlo per la tua architettura che non lo usa affatto.

Un esempio per mvp è https://github.com/antoniolg/androidmvp

Cos’è MVC? L’architettura MVC è uno dei modelli più vecchi disponibili per ottenere la separazione delle preoccupazioni. MVC è costituito da tre livelli, vale a dire, modello, vista e controller.

Il classico MVC esisteva in un momento in cui ogni controllo / gadget che esisteva sullo schermo era considerato stupido e ciascun controllo è abbinato al proprio controller per gestire le interazioni dell’utente che si verificano su di essi. Quindi, se esistono 10 gadget, devono esistere 10 controller. In questo scenario, ogni gadget viene considerato come una vista. L’avvento dei sistemi GUI di Windows ha cambiato questa immagine. La relazione Control-Controller divenne obsoleta. I controlli hanno guadagnato l’intelligenza per rispondere alle azioni avviate dall’utente. Nel mondo Windows, view è una superficie in cui sono presenti tutti i controlli / i gadget, quindi è necessario un solo controller. La vista può ricevere eventi e raggiungere i controllori aiuta a fare ulteriori elaborazioni.

Esempio di codice per mvc in Android http://androidxample.com/Use_MVC_Pattern_To_Create_Very_Basic_Shopping_Cart__-_Android_Example/index.php?view=article_discription&aid=116&aaid=138

La differenza tra entrambi è disponibile qui http://www.codeproject.com/Articles/288928/Differenze- tra-MVC-e-MVP-for- Beginners

Ora dalla mia esperienza è necessario utilizzare MVP per il progetto basato su Android, perché ha migliorato la versione di MVC Model.

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

Se sto lavorando in un team che ha già un buon background nello stile di sviluppo di moduli Web, è molto più semplice introdurre MVP che MVC. Direi che MVP in questo scenario è una vittoria veloce.

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

Lascio qui un link a 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

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

In MVP puoi avere una singola visualizzazione che funziona con più tipi di relatori e un singolo relatore che lavora con diverse viste multiple.

MVP di solito utilizza una sorta di framework vincolante, come il framework di binding Microsoft WPF o vari framework di binding per HTML5 e Java.

In questi framework, l’interfaccia utente / HTML5 / XAML è a conoscenza di quale proprietà del relatore viene visualizzata ogni elemento dell’interfaccia utente, quindi quando si associa una vista a un presentatore, la vista cerca le proprietà e sa come disegnare i 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 sorta di presentatore di automobili, espone le proprietà della macchina (anno, costruttore, posti, ecc.) Alla vista. La vista sa che il campo di testo chiamato ‘car maker’ deve mostrare la proprietà Maker presenter.

Puoi quindi associare alla vista molti tipi diversi di presentatore, tutti devono avere la proprietà Maker – può essere di un aereo, di un treno o di qualsiasi cosa, la vista non interessa. La vista richiama i dati dal presentatore, indipendentemente dal fatto che, purché implementa un’interfaccia concordata.

Questo framework vincolante, se lo spogli, è in realtà il controller 🙂

E così, puoi vedere MVP come un’evoluzione di MVC.

MVC è ottimo, ma il problema è solitamente il suo controller per visualizzazione. Il controller A sa come impostare i campi della Vista A. Se ora vuoi che la Vista A visualizzi i dati del modello B, hai bisogno del Controller A per conoscere il modello B, o hai bisogno del Controller A per ricevere un object con un’interfaccia – che è come MVP solo senza i binding, oppure è necessario riscrivere il codice del set UI nel controller B.

Conclusione – MVP e MVC sono entrambi disaccoppiati di modelli dell’interfaccia utente, ma MVP di solito utilizza un framework di binding che è MVC sotto. THUS MVP ha un livello di architettura superiore rispetto a MVC e un pattern di wrapper superiore a MVC.

La mia umile visione breve: MVP è per le grandi scale e MVC per le piccole scale. Con MVC, a volte sento che la V e la C possono essere visti come due lati di un singolo componente indivisibile piuttosto direttamente legato a M, e uno inevitabilmente cade su questo quando si scende a scale più corte, come controlli dell’interfaccia utente e widget di base. A questo livello di granularità, MVP ha poco senso. Quando invece si va 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ù di MVP.

Esistono molte versioni di MVC, questa risposta riguarda MVC originale in Smalltalk. In breve, lo è immagine di mvc vs mvp

Questo talk droidcon NYC 2017 – Clean app design con Architecture Components lo chiarisce

inserisci la descrizione dell'immagine qui inserisci la descrizione dell'immagine qui

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

IMO, MVP è una versione migliorata di MVC in cui sostanzialmente separa la preoccupazione di ciò che mostrerai (i dati) da come mostrerai (la vista). Presenter include la logica aziendale della tua interfaccia utente, impone implicitamente quali dati devono essere presentati e ti fornisce un elenco di modelli di visualizzazione stupidi. E quando arriva il momento di mostrare i dati, basta semplicemente colbind la vista (probabilmente include gli stessi id) all’adattatore e impostare i relativi campi di visualizzazione usando quei modelli di vista con una quantità minima di codice introdotta (usando solo setter). Il vantaggio principale è che puoi testare la tua logica di business dell’interfaccia utente con molte / varie visualizzazioni, come mostrare elementi in un elenco orizzontale o in un elenco verticale.

In MVC, parliamo attraverso le interfacce (confini) per incollare diversi livelli. Controller è un plug-in per la nostra architettura ma non ha una tale limitazione da imporre cosa mostrare. In questo senso, MVP è una sorta di MVC con un concetto di viste che può essere collegato al controller tramite gli adattatori.

Spero che questo aiuti meglio.

MVP

MVP è l’acronimo di Model – View- Presenter. Ciò è emerso all’inizio del 2007, quando Microsoft ha introdotto applicazioni per Windows Smart Client.

Presentatore agisce come ruolo di supervisione in MVP che associa gli eventi e le logiche di business ai modelli.

Visualizza l’associazione degli eventi verrà implementata in Presenter da un’interfaccia di visualizzazione.

View è l’iniziatore per gli input dell’utente e quindi delega gli eventi a Presenter e presenter gestisce i binding di eventi e ottiene i dati dai modelli.

Vantaggi: la vista ha solo un’interfaccia utente, nessuna logica Elevato livello di testabilità

Contro: Bit complesso e più lavoro quando si implementano i binding di eventi

MVC

MVC è l’acronimo di Model-View-Controller. Controller è responsabile della creazione di modelli e rendering di viste con modelli vincolanti.

Controller è l’iniziatore e decide quale vista visualizzare.

Pro: Enfasi sul principio di responsabilità unica Elevato livello di testabilità

Contro: A volte troppo carico di lavoro per i controller, se si tenta di rendere più viste nello stesso controller.

Molte persone non sanno esattamente quale sia la differenza tra Controller e Presenter rispettivamente in MVC e MVP.

è una semplice equazione dove

MVC View = Visualizza e presentatore di MVP

Modello MVP = Controller e modello di MVC

maggiori informazioni rimandano a questo http://includeblogh.blogspot.com.eg/2016/07/the-difference-and-relationship-between.html

La risposta più semplice è come la vista interagisce con il modello. In MVP la vista è legata al presentatore, che funge da intermediario tra la vista e il modello, prendendo input dalla vista, ottenendo dati dal modello, quindi eseguendo una logica di business e infine aggiornando la vista. In MVC il modello aggiorna la vista direttamente anziché tornare indietro attraverso il controller.