Cosa sono MVP e MVC e qual è la differenza?

Question

Quando si guarda oltre il RAD (trascina e configura) modo di costruire interfacce utente che molti strumenti incoraggiano, è probabile che ti imbatti in tre modelli di progettazione chiamati Modello-View-Controller, Modello-View-Presenter E Modello-View-ViewModel.La mia domanda è composta da tre parti:

1. Quali problemi affrontano questi modelli?
2. In cosa sono simili?
3. Come sono differenti?

Answer 1

Modello-View-Presenter

In MVP, Presenter contiene la logica aziendale dell'interfaccia utente per la vista.Tutte le chiamate dal delegato View direttamente a Presenter.Anche il Presenter è disaccoppiato direttamente dalla View e dialoga con essa attraverso un'interfaccia.Questo per consentire la derisione della View in un test unitario.Un attributo comune di MVP è che devono esserci molti invii bidirezionali.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 nei Web Form.Il motivo è che la vista viene sempre creata per prima dal runtime ASP.NET.Puoi scopri di più su entrambe le varianti.

Due varianti principali

Visualizzazione passiva: La vista è quanto più stupida possibile e contiene quasi zero logica.Il Presentatore è un intermediario 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 Presentatore li sottoscrive per aggiornare la Vista.Nella Visualizzazione passiva non è presente alcun collegamento diretto ai dati, invece la Visualizzazione espone le proprietà del setter che il Presenter utilizza per impostare i dati.Tutto lo stato è gestito nel Presenter e non nella View.

• Pro:massima superficie di provabilità;netta separazione tra vista e modello
• Contro:più lavoro (ad esempio tutte le proprietà del setter) poiché stai eseguendo tu stesso tutta l'associazione dei dati.

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

• Pro:sfruttando l'associazione dati la quantità di codice viene ridotta.
• Contro:c'è meno superficie testabile (a causa dell'associazione dati) e c'è meno incapsulamento nella vista poiché comunica direttamente con il modello.

Modello-View-Controller

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

    Action in the View
        -> Call to Controller
        -> Controller Logic
        -> Controller returns the View.

Un'altra grande differenza di MVC è che la vista non si lega direttamente al modello.La vista viene semplicemente renderizzata ed è completamente senza stato.Nelle implementazioni di MVC la vista solitamente non avrà alcuna logica nel codice sottostante.Questo è contrario a MVP dove è assolutamente necessario perché, se la View non delega al Presenter, non verrà mai chiamata.

Modello di presentazione

Un altro modello da considerare è il Modello di presentazione modello.In questo modello non è presente alcun relatore.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 verrebbero mai inserite in un modello di dominio in quanto costituirebbe una violazione della separazione degli interessi.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 comandi che la vista utilizza per invocare 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.Questo modello è un candidato molto valido per l'uso nelle applicazioni WPF ed è anche chiamato Modello-View-ViewModel.

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

Answer 2

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

MVC

MVP

Answer 3

Ne ho parlato sul blog qualche tempo fa, citando L'eccellente post di Todd Snyder sulla differenza tra i due:

Ecco le differenze chiave tra i modelli:

Modello MVP

• La vista è accoppiata in modo più debole al modello.Il presentatore è responsabile del legame del modello alla vista.
• Test unitario più facile da unità perché l'interazione con la vista è attraverso un'interfaccia
• Di solito visualizza la mappa del presentatore uno a uno.Le viste complesse possono avere multi presentatori.

Modello MVC

• Il controller si basa su comportamenti e può essere condiviso attraverso le viste
• Può essere responsabile della determinazione della vista da visualizzare

È la migliore spiegazione che ho trovato sul web.

Answer 4

Ecco le illustrazioni che rappresentano il flusso di comunicazione

Answer 5

MVP lo è non necessariamente uno scenario in cui la View è al comando (vedi ad esempio l'MVP di Taligent).
Trovo un peccato che le persone continuino a predicarlo come un modello (Visualizzazione responsabile) anziché come un anti-modello in quanto contraddice "È solo una visione" (Pragmatic Programmer)."È 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 convenientemente scusa il progettista di Microsoft dall'incoraggiare cattive pratiche.

Per essere del tutto sincero, penso che le preoccupazioni di fondo di MVC siano valide per qualsiasi implementazione MVP e le differenze siano quasi interamente semantiche.Finché si segue la separazione degli interessi tra la vista (che visualizza i dati), il controller (che inizializza e controlla l'interazione dell'utente) e il modello (i dati e/o i servizi sottostanti)), allora si ottengono i vantaggi di MVC .Se stai ottenendo i vantaggi, allora a chi importa davvero se il tuo modello è MVC, MVP o Supervising Controller?L'unica vero il pattern rimane come MVC, il resto ne ha solo gusti diversi.

Prendere in considerazione Questo articolo molto interessante che elenca in modo completo una serie di queste diverse implementazioni.Potresti notare che fondamentalmente fanno tutti la stessa cosa ma in modo leggermente diverso.

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

Answer 6

MVP:la vista è responsabile.

La vista, nella maggior parte dei casi, crea il proprio presentatore.Il relatore interagirà con il modello e manipolerà la vista attraverso un'interfaccia.La vista a volte interagirà con il relatore, solitamente attraverso qualche interfaccia.Ciò si riduce all'implementazione;vuoi che la vista chiami metodi sul relatore o vuoi che la vista abbia eventi ascoltati dal relatore?Si riduce a questo:La vista conosce il presentatore.La vista delega al presentatore.

MVC:il controllore è responsabile.

Il controller viene creato o vi si accede 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 titolare del trattamento crea e gestisce la vista;la vista è schiava del controller.La vista non conosce il controller.

Answer 7

MVC (controller vista modello)

L'input è diretto prima al Controller, non alla vista.Tale input potrebbe provenire da un utente che interagisce con una pagina, ma potrebbe anche provenire semplicemente dal semplice inserimento di un URL specifico in un browser.In entrambi i casi, si tratta di un controller con cui si interfaccia per avviare alcune funzionalità.Esiste una relazione molti-a-uno tra il Controller e la View.Questo perché un singolo controller può selezionare diverse visualizzazioni di cui eseguire il rendering in base all'operazione eseguita.Notare la freccia unidirezionale dal controller alla vista.Questo perché la View non ha alcuna conoscenza o riferimento al controller.Il Controller restituisce il Modello, quindi c'è conoscenza tra la View e il Modello previsto che viene passato in esso, ma non il Controller che lo fornisce.

MVP (presentatore vista modello)

L'input inizia con la vista, non con il presentatore.Esiste una mappatura uno a uno tra la vista e il presentatore associato.La vista contiene un riferimento al presentatore.Il Presenter reagisce anche agli eventi attivati ​​dalla View, quindi è consapevole della View a cui è associato.Il Presenter aggiorna la vista in base alle azioni richieste che esegue sul modello, ma la vista non è a conoscenza del modello.

Per più Riferimento

Answer 8

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

Utente:Fare clic su fare clic…

Visualizzazione:Chi è quello?[MVP|MVC]

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

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

( Visualizzazione chiamando il Presentatore|Controllore … ) [MVP|MVC]

Visualizzazione:EHI Presentatore|Controllore, un Utente ha appena cliccato sul pulsante di ricerca, cosa devo fare?[MVP|MVC]

Presentatore|Controllore:EHI Visualizzazione, c'è qualche termine di ricerca in quella pagina?[MVP|MVC]

Visualizzazione:Sì,… eccolo… “pianoforte” [MVP|MVC]

Presentatore:Grazie Visualizzazione,… nel frattempo sto cercando il termine di ricerca su Modello, mostragli/le una barra di avanzamento [MVP|MVC]

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

Presentatore|Controllore:EHI Modello, Hai qualche corrispondenza per questo termine di ricerca?:“pianoforte” [MVP|MVC]

Modello:EHI Presentatore|Controllore, fammi controllare … [MVP|MVC]

( Modello sta effettuando una query sul database dei film...) [MVP|MVC]

( Dopo un po ...)

-------------- È qui che 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 Visualizzazione) [MVP|MVC]

Presentatore:Grazie per aver aspettato Visualizzazione, ho trovato per te un elenco di risultati corrispondenti e li ho organizzati in un formato presentabile:["Insegnante di pianoforte 2001","Pianoforte 1993"].Mostralo all'utente in un elenco verticale.Inoltre, nascondi ora la barra di avanzamento [MVP]

Controllore:Grazie per aver aspettato Visualizzazione, Ho chiesto Modello sulla tua query di ricerca.Dice di aver trovato un elenco di risultati corrispondenti e di averli archiviati in una variabile denominata "searchResultsList" all'interno della sua istanza.Puoi ottenerlo da lì.Inoltre, nascondi ora la barra di avanzamento [MVC]

Visualizzazione:Grazie mille Presentatore [MVP]

Visualizzazione:Grazie "Controllore" [MVC] (Ora il Visualizzazione si interroga:Come dovrei presentare i risultati che ottengo da Modello all'utente?L'anno di produzione del film dovrebbe essere il primo o l'ultimo...?Dovrebbe essere in un elenco verticale o orizzontale?...)

Se sei interessato, ho scritto una serie di articoli che trattano modelli architettonici delle 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.

Answer 9

• MVP = Modello-Visualizzatore-Presentatore

• MVC = Model-View-Controller

  1. Entrambi i modelli di presentazione.Separano le dipendenze tra un modello (pensa agli oggetti di dominio), il tuo schermo/pagina web (la vista) e il modo in cui dovrebbe comportarsi la tua interfaccia utente (presentatore/controller)
  2. Sono abbastanza simili nel concetto, le persone inizializzano il presentatore/controller in modo diverso a seconda dei gusti.
  3. Un ottimo articolo sulle differenze è Qui.La cosa più notevole è che il modello MVC prevede che il modello aggiorni la vista.

Answer 10

Vale anche la pena ricordare che esistono anche diversi tipi di MVP.Fowler ha suddiviso lo schema in due: Visualizzazione passiva e Controller di supervisione.

Quando si utilizza la visualizzazione passiva, la visualizzazione in genere implementa un'interfaccia a grana fine con proprietà mappate 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 assomigliare 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 visualizzazione è facile da testare ed è più semplice spostarsi tra le piattaforme dell'interfaccia utente (Web, Windows/XAML e così via).Lo svantaggio è che non puoi sfruttare cose come il databinding (che è Veramente potente in framework come WPF E Silverlight).

La seconda versione di MVP è il controller di supervisione.In tal caso la tua vista potrebbe avere una proprietà chiamata Cliente, che poi è nuovamente collegata ai widget dell'interfaccia utente.Non è necessario pensare alla sincronizzazione e alla microgestione della vista e il controller di supervisione può intervenire e aiutare quando necessario, ad esempio con una logica di interazione completata.

Il terzo "sapore" di MVP (o qualcuno forse lo chiamerebbe un modello separato) è il modello di presentazione (o talvolta indicato a Model-View-ViewModel).Rispetto all'MVP "unisci" la M e la P in un'unica classe.Hai l'oggetto cliente a cui sono associati i dati dei widget dell'interfaccia utente, ma hai anche campi aggiuntivi specifici 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 scritti da Jeremy Miller su Sommario della serie Costruisci la tua CAB.Ha coperto tutti gli aspetti 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 rivisitata:Implementazione del modello ViewModel.

Answer 11

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

• Modelli per la gestione dei dati e della logica aziendale
• Controllori per gestire l'interfaccia utente e l'applicazione
• Visualizzazioni per la gestione degli oggetti e della presentazione dell'interfaccia utente grafica

Per renderlo 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 descriveremo come implementare alcune di queste funzionalità utilizzando MVC.

Modello-View-Presenter

• IL modello sono i dati che verranno visualizzati nella vista (interfaccia utente).
• IL visualizzazione è un'interfaccia che visualizza i dati (il modello) e instrada i comandi dell'utente (eventi) al Presenter per agire su tali dati.La vista di solito ha un riferimento al suo Presenter.
• IL Presentatore è l '"intermediario" (interpretato dal controller in MVC) e ha riferimenti sia alla vista che al modello. Si prega di notare che la parola “Modello” è fuorviante.Dovrebbe piuttosto esserlo logica aziendale che recupera o manipola un modello.Ad esempio:Se disponi di un database che memorizza l'utente in una tabella di database e la tua vista desidera visualizzare un elenco di utenti, il presentatore avrà un riferimento alla logica aziendale del database (come un DAO) da cui il presentatore interrogherà un elenco di utenti.

Se vuoi vedere un esempio con un'implementazione semplice, controlla Questo messaggio su GitHub

Un flusso di lavoro concreto per interrogare e visualizzare un elenco di utenti da un database potrebbe funzionare in questo modo:

Quale è differenza fra MVC E MVP modelli?

Modello MVC

• I controller si basano sui comportamenti e possono essere condivisi tra visualizzazioni

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

Modello MVP

• La vista è accoppiata in modo più debole al modello.Il presentatore è responsabile dell'associazione del modello alla vista.

• È più semplice eseguire il test unitario perché l'interazione con la vista avviene tramite un'interfaccia

• Di solito visualizza la mappa del presentatore uno a uno.Le visualizzazioni complesse possono avere più presentatori.

Answer 12

Ognuno di essi affronta problemi diversi e possono anche essere combinati insieme per avere qualcosa di simile a quello riportato di seguito

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

Answer 13

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 (Visualizzazione).In alcuni casi il modello può essere utilizzato anche per trasformare un'origine dati in un'astrazione di livello superiore.Un buon esempio di ciò è il Progetto MVC Storefront.

C'è una discussione Qui per quanto riguarda le differenze tra MVC e 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 relatore di accedere al modello e interagire con la vista.

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

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

Answer 14

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 mentre MVC è un approccio basato su Front Controller.Ciò significa che nel ciclo di vita della pagina 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 evolutivo del modulo web.MVC su altri cambiamenti cambia completamente il gioco perché la richiesta viene intercettata dalla classe del controller prima della carica, la logica aziendale viene eseguita lì e quindi al risultato finale del controller che elabora i dati appena scaricati nella pagina ("Visualizza") in questo Senso, MVC sembra (almeno per me) molto per supervisionare il sapore del controller di MVP migliorato con il motore di routing

Entrambi abilitano il TDD e presentano vantaggi e svantaggi.

La decisione su come sceglierne uno 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 uno non si sentisse così a suo agio in cose come il ciclo di vita della pagina ecc. MVC potrebbe essere un modo per andare qui.

Ecco ancora un altro collegamento al post del blog che fornisce ulteriori dettagli su questo argomento

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

Answer 15

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

Se lavoro in un team che ha già una buona conoscenza dello stile di sviluppo dei moduli Web, è molto più semplice introdurre MVP che MVC.Direi che MVP in questo scenario è una vittoria rapida.

La mia esperienza mi dice che spostare un team dai moduli Web a MVP e quindi da MVP a MVC è relativamente semplice;il passaggio 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

Answer 16

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

In MVP puoi avere un'unica visualizzazione che lavora con più tipi di relatori e un singolo relatore che lavora con diverse visualizzazioni multiple.

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

In questi framework, UI/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, ad esempio, il modello è un'auto, il presentatore è una sorta di presentatore di auto, espone alla vista le proprietà dell'auto (anno, produttore, sedili, ecc.).La vista sa che il campo di testo chiamato "produttore di automobili" deve visualizzare la proprietà Creatore del presentatore.

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

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

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

MVC è fantastico, ma il problema è che di solito è il suo controller per visualizzazione.Il controller A sa come impostare i campi della vista A.Se ora, vuoi che View A visualizzi i dati del modello B, hai bisogno del Controller A per conoscere il modello B, oppure hai bisogno del Controller A per ricevere un oggetto con un'interfaccia, che è come MVP solo senza i collegamenti, oppure devi riscrivere il codice impostato dell'interfaccia utente nel controller B.

Conclusione: MVP e MVC sono entrambi disaccoppiati dai modelli di interfaccia utente, ma MVP di solito utilizza un framework di associazione che è MVC sottostante.QUINDI MVP si trova a un livello architettonico più elevato rispetto a MVC e a un modello wrapper superiore a MVC.

Answer 17

La mia umile breve visione:MVP è per grandi scale e MVC per piccole scale.Con MVC, a volte ho la sensazione che la V e la C possano essere viste come due lati di un singolo componente indivisibile piuttosto direttamente legato a M, e si cade inevitabilmente in 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, al contrario, si passa a scale più ampie, l'interfaccia corretta diventa più importante, lo stesso vale per l'assegnazione inequivocabile delle responsabilità, e qui arriva MVP.

D'altra parte, questa regola pratica di scala, 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, piuttosto che MVP.

Answer 18

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 sostanzialmente separi la preoccupazione di ciò che mostrerai (i dati) da come mostrerai (la visualizzazione).Presenter include in un certo senso la logica aziendale della tua interfaccia utente, impone implicitamente quali dati dovrebbero essere presentati e ti fornisce un elenco di modelli di visualizzazione stupidi.E quando arriva il momento di mostrare i dati, collega semplicemente la tua vista (probabilmente include gli stessi ID) all'adattatore e imposta i campi di visualizzazione pertinenti utilizzando quei modelli di visualizzazione con una quantità minima di codice introdotta (semplicemente usando i setter).Il vantaggio principale è che puoi testare la logica aziendale dell'interfaccia utente rispetto a molte/varie visualizzazioni come la visualizzazione di elementi in un elenco orizzontale o verticale.

In MVC parliamo attraverso interfacce (confini) per incollare diversi livelli.Il controller è un plug-in della nostra architettura ma non ha tali restrizioni per imporre cosa mostrare.In questo senso, MVP è una specie di MVC con il concetto di visualizzazioni collegabili al controller tramite adattatori.

Spero che questo aiuti meglio.

Answer 19

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

Questo discorso droidcon NYC 2017: design pulito delle app con componenti di architettura lo chiarisce

Answer 20

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.

Answer 21

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

(IL articolo corrisponde anche a ciò che ha detto lo zio Bob Martin in uno dei suoi discorsi:che MVC è stato originariamente progettato per i piccoli componenti dell'interfaccia utente, non per l'architettura del sistema)

Answer 22

MVP

MVP sta per Modello - Visualizza - Presenter.Ciò è emerso all'inizio del 2007, quando Microsoft ha introdotto le applicazioni Windows Smart Client.

Il presentatore funge da ruolo di supervisione in MVP che vincola Visualizza eventi e logiche aziendali dai modelli.

L'associazione degli eventi di visualizzazione 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 il presentatore gestisce le associazioni di eventi e ottiene dati dai modelli.

Professionisti:La vista è avere solo l'interfaccia utente non alti livelli di testabilità

Contro:Un po' complesso e richiede più lavoro quando si implementano le associazioni di eventi

MVC

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

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

Professionisti:Enfasi sul principio di responsabilità singola alto livello di testabilità

Contro:A volte troppo carico di lavoro per i controller, se si tenta di eseguire il rendering di più visualizzazioni nello stesso controller.