Buona analogia per i pattern MVP e MVC?

2

Per essere onesti, sono uno studente qui, ma ho visto molte domande da parte degli insegnanti che chiedevano modi per spiegare, e non ne ho trovato uno per i pattern MVP e MVC.

Il mio problema è che ho studiato queste pagine, ho scritto molti tutorial e ho seguito degli esempi e ho persino lavorato a progetti scolastici con loro, ma sento che non riesco a cogliere l'essenza di questi schemi . Ogni volta che devo fare qualcosa con loro divento "lento" come se non comprendessi, probabilmente, perché non capisco qualcosa.

Quindi la mia domanda è, c'è una buona analogia o una chiara spiegazione ai modelli MVP e MVC individualmente e / o comparabili?

    
posta Dragonturtle 20.06.2017 - 12:24
fonte

1 risposta

6

Ci sono 3 varianti principali dello stesso modello base:

  • Model-View-Controller: il nonno di tutti loro. Originariamente definito con Smalltalk
  • Model-View-Presenter: variante creata principalmente per gestire i limiti dell'architettura Windows Form. Si adatta alle tecnologie in cui l'interfaccia utente non può collegarsi direttamente al modello
  • Model-View-View Model: Variant creato principalmente per gestire le applicazioni basate su XAML di Microsoft (WPF, Silverlight, UAP). Successivamente adottato da un numero di framework Javascript come Angular.

Per comprendere le varianti, aiuta a capire il modello architettonico originale e le preoccupazioni separate. La verità è che tutte e tre le varianti concordano sia sul modello che sulla vista, con differenze nel modo in cui modellate il controllo.

Model-View-Controller

Il concetto Smalltalk di un modello era qualcosa chiamato un modello di dominio. La differenza principale è che il modello di dominio presenta anche i metodi che ogni oggetto deve eseguire all'interno del dominio del client. Essenzialmente è l'applicazione senza alcuna interfaccia utente.

Il concetto Smalltalk di una vista era qualcosa che poteva legarsi direttamente al tuo modello. I pulsanti si legherebbero a un metodo, le caselle di testo si legherebbero ai setter / getter, ecc. Dovrebbero anche legarsi a qualcosa chiamato Controller.

Il concetto Smalltalk di un Controller è una funzionalità che è in generale per l'applicazione. Ad esempio le voci di menu che hanno le opzioni "Salva" e "Carica", ecc. Sono legate a un Controller che a sua volta fa cose con il Modello. Il controller "Salva" è un oggetto che prende la radice del dominio e la serializza su disco o qualcosa del genere.

Le applicazioni MVC basate sul Web hanno qualcosa chiamato un Controller che associa gli URL a metodi che interagiscono con un Modello e lo collegano a una vista.

Model-View-Presenter

WinForms (Windows Forms Applications) e cose simili non hanno binding diretto. Ci sono diverse funzioni in un'interfaccia utente in cui la modifica del valore in una casella combinata influisce sullo stato in altri luoghi.

Tipicamente per questa e versioni successive il modello è più di un modello "Dati". In altre parole, sono solo le proprietà che costituiscono i dati per i tuoi oggetti di business.

Il Presentatore è la combinazione di un'interfaccia e un'implementazione. L'interfaccia è qualcosa di cui il modello è a conoscenza, quindi le modifiche che provengono dal modello possono aggiornare la vista. L'implementazione conosce la vista e lavora intimamente con essa. Gestisce le modifiche relative all'interfaccia utente che devono verificarsi e quindi utilizza un callback per consentire al modello di aggiornarsi.

C'è sempre un'implementazione del presentatore con ogni vista. L'interfaccia può essere riutilizzata, ma in genere non lo è.

È molto lavoro, quindi molte persone non usano MVP. È l'unico modo per rendere testabili le applicazioni basate su WinForms.

Model-View-View Model

Con le app basate su XAML e la maggior parte dei framework per app a pagina singola javascript, abbiamo di nuovo il concetto di associazione diretta al nostro modello. Il modello e la vista sono molto simili ai concetti MVC originali, ma la maggior parte delle persone utilizza un modello di dati più semplice anziché il modello di dominio completo.

Un Visualizza modello definisce tutte le proprietà e le interazioni specifiche della vista e espone il modello attraverso una proprietà associabile denominata "Modello". Ciò consente al modello di ignorare le preoccupazioni dell'interfaccia utente, ma consente comunque alla vista di essere interattiva come vogliamo. La vista può collegarsi direttamente al modello o alle proprietà specifiche della vista.

In pratica di solito c'è un modello di vista per vista, anche se in teoria non è necessario.

In conclusione:

  • MVC ha iniziato tutto.
  • I modelli rappresentano i dati aziendali e la logica in tutte e tre le varianti
  • Le viste rappresentano ciò con cui l'utente interagisce in tutte e tre le varianti
  • La differenza principale è il modo in cui la vista interagisce con il modello
    • I controllori rispondono alla vista e agiscono sul modello
    • I relatori fungono da ponte tra il modello e la vista quando non puoi interagire automaticamente con esso (cioè il bind).
    • Visualizza i modelli aggiungi uno strato di modelli specifici della vista che la vista può associare e interagire con il modello in questo modo

Quale effettivamente si finisce per usare è davvero dettato dalla tecnologia che si sta utilizzando. Tutti e tre consentono di testare l'applicazione a fondo senza invocare un'interfaccia utente.

    
risposta data 20.06.2017 - 15:19
fonte

Leggi altre domande sui tag