Quali sono i miglioramenti di MVP su MVC?

Question

Quali sono i miglioramenti di MVP su MVC?

#1 da (62 voti)
#2 da (6 voti)

49

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

Quali problemi hanno affrontato, che MVC non ha risolto (o risolto male), ma MVP può risolvere? Quali problemi ha intenzione di 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:

Now onto Model View Presenter, which was a response to the inadequacies of the MVC pattern when applied to modern component based graphical user interfaces. In modern GUI systems, GUI components themselves handle user input such as mouse movements and clicks, rather than some central controller.

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"?

design design-patterns mvc mvp

posta Victor 14.12.2016 - 16:37

fonte

2 risposte

Leggi altre domande sui tag design design-patterns mvc mvp

Entity Framework con grandi sistemi - come dividere i modelli? Non capisco come TDD mi aiuti a ottenere un buon design se ho bisogno di un progetto per iniziare a testarlo

score 62 · Answer 1

MVC è concettualmente elegante:

l'input dell'utente viene 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 spesso contiene 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 relatore, 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 sottoposta a test dell'unità in termini di presentatore, poiché descrive lo stato dell'interfaccia utente. All'interno del test dell'unità, sostituiamo la vista con un driver di prova che effettua chiamate al relatore.
Poiché l'interfaccia utente è isolata dalla logica dell'applicazione, entrambe possono essere sviluppate indipendentemente.

Ma ci sono anche alcuni svantaggi di questo approccio:

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

score 6 · Answer 2

In MVP, Presenter sostituisce il Controller di MVC. La differenza tra i due è che il Presenter manipola direttamente la vista. È progettato per i framework dell'interfaccia utente che sono principalmente basati su eventi (come Windows Form) senza un strong supporto per l'associazione di dati complessi che presterebbe il pattern MVVM (come WPF). Altrimenti un sacco di logica per la gestione dello stato di visualizzazione e l'aggiornamento del modello di supporto si trovano nella vista stessa.