Quali sono i miglioramenti di MVP su MVC?

Ho letto per tre giorni i modelli Model-View-Controller (MVC) e Model-View-Presenter (MVP) . E c'è una domanda che mi dà molto fastidio. Perché i progettisti di software hanno inventato MVP, quando esisteva già un MVC?

Quali problemi hanno dovuto affrontare, che MVC non ha risolto (o risolto male), ma MVP può risolvere? Quali problemi intende risolvere MVP?

Ho letto molti articoli sulla storia e la spiegazione di MVP o sulle differenze tra MVC e MVP, ma nessuno ha avuto una risposta chiara alle mie domande.

In uno degli articoli che ho letto, è stato detto:

Ora su Model View Presenter, che è stata una risposta alle inadeguatezze del modello MVC quando applicato a interfacce utente grafiche basate su componenti moderni. Nei moderni sistemi di interfaccia grafica, i componenti della stessa interfaccia grafica gestiscono l'input dell'utente come movimenti e clic del mouse, piuttosto che un controller centrale.

Quindi, non riesco a capire, ma può effettivamente essere in un altro modo, in modo tale che i componenti della GUI non gestiscano l'input dell'utente da soli? E cosa significa esattamente "gestire da soli"?

— Vincitore
fonte

Duplicato di stackoverflow.com/questions/2056/...

— qwerty_so

Penso che sia solo "I vestiti nuovi dell'Imperatore", una nuova parola d'ordine di Mickeysoft.

— qwerty_so,

Victor, hai una domanda specifica oltre a "perché ci sono due diversi schemi?" Esistono due modelli diversi perché risolvono lo stesso problema in due modi leggermente diversi. Se aiuta, il Modello e la Vista sono essenzialmente gli stessi in entrambi i modelli. Concentrati sulle differenze tra un controller e un presentatore. Puoi trovare altro aiuto qui: linkedin.com/pulse/…

— Robert Harvey,

"Ho letto per tre giorni sui modelli MVC e MVP." Yikes. Ti suggerisco di fare un bagno caldo rilassante o saltare alcune pietre attraverso uno stagno pieno di anatra o qualcosa del genere. Questo tipo di lettura può davvero sciogliere il cervello in assenza di un'applicazione pratica!

— user1172763

Il modo in cui ottieni il tipo di risposta che desideri è costruendo qualcosa usando questi schemi. Allora sarai illuminato.

— Robert Harvey,

Risposte:

MVC è concettualmente elegante:

l'input dell'utente è gestito dal controller
il controller aggiorna il modello
il modello aggiorna la vista / l'interfaccia utente

           +---+
      +----| V |<----+
user  |    +---+     | updates
input |              |
      v              |
    +---+          +---+
    | C |--------->| M |
    +---+ updates  +---+

Tuttavia: il flusso di dati ed eventi in MVC è circolare. E la vista conterrà spesso una logica significativa (come i gestori di eventi per le azioni dell'utente). Insieme, queste proprietà rendono il sistema difficile da testare e difficile da mantenere.

L'architettura MVP sostituisce il controller con un presentatore, che media tra la vista e il modello. Questo linearizza il sistema:

       user input         updates
+---+ -----------> +---+ --------> +---+
| V |              | P |           | M |
+---+ <----------- +---+ <-------- +---+
        updates            updates

Questo ha i seguenti vantaggi:

La logica (come i gestori di eventi e lo stato dell'interfaccia utente) può essere spostata dalla vista al presentatore.
L'interfaccia utente può essere testata dall'unità in termini di presentatore, poiché descrive lo stato dell'interfaccia utente. All'interno dell'unità di test, sostituiamo la vista con un driver di test che effettua chiamate al presentatore.
Poiché l'interfaccia utente è isolata dalla logica dell'applicazione, entrambi possono essere sviluppati in modo indipendente.

Ma ci sono anche alcuni svantaggi di questo approccio:

Richiede uno sforzo maggiore.
Il presentatore può facilmente trasformarsi in una "classe divina" non mantenibile.
L'applicazione non ha un singolo asse MVP, ma più assi: uno per ogni schermata / finestra / pannello nell'interfaccia utente. Ciò può semplificare la tua architettura o complicarla in modo orribile.

— amon
fonte

Buona risposta, ma MVC dei nostri giorni generalmente non fa molto (se c'è ne) uso dei gestori di eventi, tranne forse per la convalida dei moduli locali, e non considero tali eventi parte di MVC. Ecco perché abbiamo MVP e MVVM. MVC è essenzialmente lato server.

— Robert Harvey,

@amon, grazie per la tua risposta, mi dice molte cose. E tu dici che avere diversi assi nell'applicazione può semplificare l'architettura. Ho incontrato questa idea in molti articoli e ne sono stati citati, come uno dei motivi principali per inventare MVP, perché MVC non soddisfa i requisiti complessi delle GUI. Cioè, quali requisiti corrispondono a MVP e come risolve tali requisiti? Scusate se sono persistente, ma REALMENTE la bacchetta per capirlo bene.

— Victor,

@Victor Non esiste uno schema migliore, ma i compromessi sono diversi. MVC può corrispondere a requisiti complessi. In termini di architettura, MVP applica una relazione 1: 1 tra viste e presentatori: ogni vista ha il proprio relatore, ogni relatore è collegato a una vista. In MVC esiste una relazione n: m: una vista può inviare input utente a più controller diversi e un controller può ricevere input da molte visualizzazioni. Questo è più flessibile, ma anche più caotico: non c'è un “asse” chiaro in MVC.

— amon,

@Victor Non ho molta esperienza con le GUI, quindi probabilmente c'è molto che non ho menzionato. L'ultima GUI che ho fatto è stata un casino assoluto perché non sapevo di MVP a quel punto - un flusso di dati e controllo linearizzato sarebbe stato un enorme miglioramento.

— amon,

@RobertHarvey Direi che ciò che il Web chiama "MVC" non è mai stato "MVC" dalla definizione originale. Chiunque abbia dirottato l'acronimo dovrebbe essere colpito alla testa per aver scelto un termine carico e aver confuso tutti.

— jpmc26,

In MVP, Presenter sostituisce il controller MVC. La differenza tra i due è che il Presenter manipola direttamente la vista. È progettato per i framework dell'interfaccia utente che sono principalmente guidati da eventi (come Windows Form) senza un forte supporto per l'associazione di dati avanzati che si presterebbe al modello MVVM (come WPF). Altrimenti gran parte della logica per la gestione dello stato della vista e l'aggiornamento del modello di supporto risiederebbe nella vista stessa.

— Michael Brown
fonte