Differenza tra MVVM e MVP

Lo scopo dello sviluppo del software è quello di creare soluzioni che soddisfino esigenze e problemi per utenti e aziende. Per ottenere questo, diverse tecnologie e modelli di architettura come Model-View-ViewModel (MVVM) e Model-View-Presenter (MVP) sono utilizzati.

Come per tutto ciò che viene prodotto, il primo passo è la fase di progettazione e progettazione. Il processo di progettazione del software può essere una specifica basata sul set di strumenti di tecnologia preferito e può comprendere tutte le attività, dalla concezione alla pianificazione, all'implementazione, agli aggiornamenti e alle modifiche.

Copre la progettazione architettonica di basso livello e di alto livello, basata su modelli di architettura selezionati e mappa le soluzioni riutilizzabili utilizzando modelli di progettazione.

Struttura dell'applicazione software

L'architettura software definisce la struttura di un'applicazione che soddisfa i requisiti tecnici, operativi e dell'utente e fa riferimento a come il codice è organizzato e gestito.

Decidere sull'architettura di un'applicazione software è fondamentale in quanto non è una parte facile e mutevole di un'applicazione già sviluppata; quindi il modello architettonico deve essere deciso prima che inizi la programmazione.

I modelli architettonici sono in qualche modo diversi dai modelli di progettazione poiché il loro ambito è molto più ampio affrontando problemi più tecnici come le prestazioni e le limitazioni dell'hardware e l'elevata disponibilità. Esempi di diversi modelli di architettura sono MVC, MVVM e MVP.

D'altra parte, i modelli di progettazione sono best practice formalizzate che facilitano lo sviluppo orientato agli oggetti riutilizzabile e sono più facili da gestire e modificare rispetto all'architettura di un'applicazione. 

Modelli di architettura

Model View Controller (MVC) è stato uno dei primi modelli architettonici sviluppati per le applicazioni web, guadagnando popolarità dalla metà alla fine degli anni Novanta, in particolare con la comunità Java.

I framework più recenti, come Django per Python e Rails (Ruby on Rails), si concentrano molto sulla distribuzione rapida, motivo per cui MVC sta conquistando la quota di mercato come grande attrazione per i modelli architettonici.

Tradizionalmente, lo sviluppo dell'interfaccia utente conteneva un sacco di codice per gestire la logica complicata, quindi i pattern di architettura sono stati progettati per ridurre il codice a livello dell'interfaccia utente (UI), rendendolo più "pulito" e gestibile.

Quindi, con il pattern MVC, è composta una applicazione web

  • Modello (dati)
  • vista (interfaccia per visualizzare e manipolare i dati)
  • controllore (operazioni e azioni eseguite sui dati)

Il Modello gestisce i dati e la logica aziendale e ci sono no dipendenze tra il Modello e il controllore o vista.

Il vista presenta i dati all'utente nel formato supportato e nel layout richiesto, e quando il file controllore riceve richieste degli utenti (per recuperare i dati), chiama le risorse necessarie necessarie per completare la richiesta.

Applichiamo questo modello alla costruzione di un negozio di libri online.

Gli utenti possono cercare, visualizzare, registrare e acquistare libri, nonché gestire i propri profili e elenchi di libri. Quando un utente fa clic sulla categoria SCI-FI, tutti i libri correlati devono essere visualizzati come disponibili.

Il Controller gestire le azioni che gestiscono i libri (elenco, aggiunta, visualizzazione, ecc.). Ci possono essere multipli Controller con un main controllore 'dirigere il traffico'.

Per questo esempio, il controllore è denominato controller_books.php e il Modello (ad esempio model_books.php) gestisce i dati e la logica relativi ai libri.

Infine, diverso Visualizzazioni sarà richiesto, come quando si aggiungono libri al carrello online o quando si visualizzano i dettagli del libro con immagini e recensioni.

Il controller_books.php riceve l'azione (richiesta dell'utente) dal principale controllore (per esempio. index.php). Il controller_books.php analizza la richiesta e chiama il model_books.php (i dati) per restituire l'elenco dei libri SCI-FI.

La responsabilità del Modello è quello di fornire tali informazioni, utilizzando qualsiasi logica applicata (utilizzando i filtri di ricerca). Il controllore quindi prende le informazioni e le passa al relativo vista (ricerca vista, vista stampa, vista dettagli, ecc.) e le informazioni sono presentate (tramite il file vista) all'utente che ha avviato la richiesta.

Questo è il fondamento del pattern MVC, che ha evoluto le variazioni di spawn dei modelli di architettura, come Model-View-Presenter (MVP), Model-View-ViewModel (MVVM), Hierarchical-Model-View-Controller (HMVC), e Model-View-Adapter (MVA), ecc.

Pattern MVP

Model-View-Presenter (MVP)

Il Modello MVP è in circolazione da un po 'ed è una variante di MVC. È stato progettato specificamente per l'automazione di test in cui l'obiettivo era aumentare la quantità di codice che può essere testato tramite l'automazione e il pattern risolve alcuni problemi con il livello di presentazione, isolando la logica di business dall'interfaccia utente.

Lo schermo è la Vista, i dati visualizzati sono il Modello e il Presenter aggancia i due insieme.

MVP comprende le seguenti componenti con responsabilità separate:

  • Modello (definisce i dati da visualizzare)
  • vista (visualizza i dati dal modello e instrada le richieste dell'utente al presentatore).
  • Presentatore (interagisce tra la vista e il modello e li unisce)

Il vista (una pagina web) visualizza e gestisce i controlli della pagina inoltrando eventi (richieste dell'utente) a Presentatore che sono stati avviati nel vista.

Il Presentatore risponde a questi eventi leggendo e aggiornando il Modello cambiare il vista e quindi, il Presenter di la responsabilità è di legare il Modello e vista.

Dopo aver guardato MVC e MVP modelli, la comunanza è entrambi hanno responsabilità separate per ogni componente e promuovono la separazione tra il vista (UI) e Modello (dati). Differenze significative tra questi modelli sono più evidenti nel modo in cui i modelli sono implementati.

MVP può essere un modello complesso da implementare per soluzioni avanzate ma sicuramente ha grandi vantaggi se implementato come soluzione ben progettata, anche se potrebbe non essere necessariamente la scelta appropriata per soluzioni semplici.

Modello MVVM

Model-View-ViewModel (MVVM)

Il MVVM modello è stato specificamente progettato per Windows Presentation Foundation (WPF) e Microsoft Silverlight, e può essere utilizzato su tutti XAML [i] piattaforme.

WPF è un sistema Microsoft che esegue il rendering di interfacce utente in programmi basati su Windows ed è stato rilasciato per la prima volta in .NET Framework 3.0.

MVVM è stato raffinato da MVC e in questo modello, il vista è attivo con comportamenti, eventi e associazione dati e il vista si sincronizza con ViewModel (che abilita la separazione della presentazione e espone metodi e comandi per gestire e manipolare il Modello.

MVVM comprende tre componenti principali:

  • Modello (rappresenta i dati con convalida e logica aziendale)
  • vista (La vista è responsabile della definizione della struttura, del layout e dell'aspetto di ciò che l'utente vede sullo schermo. Idealmente, la vista è definita puramente con XAML, con un code-behind limitato che non contiene la logica di business. vincolante tra il vista e ViewModel per visualizzare gli oggetti che sincronizzano il Modello e il ViewModel con la Vista)
  • ViewModel (separa la vista dal modello e espone metodi e comandi per manipolare i dati (modello).

Il vista riceve dati dal ViewModel (tramite associazione dati e metodi), e in fase di esecuzione, il vista cambierà quando risponderà agli eventi nel ViewModel.

Il ViewModel media tra il vista e Modello e gestisce il vista logica. Interagisce con il Modello - prendendo i dati dal Modello e presentandolo al vista da visualizzare.

Questi componenti sono tutti disaccoppiati tra loro consentendo una maggiore flessibilità per lavorare su di essi in modo indipendente, isolare i test di unità e scambiarli, senza influire su nessun altro componente.

Questa struttura consente il Modello e altri componenti per evolvere in modo indipendente, consentendo agli sviluppatori di lavorare contemporaneamente su diversi aspetti della soluzione. Ad esempio, dove i designer stanno lavorando su vista, semplicemente generano campioni di dati senza bisogno di accedere agli altri componenti. Ciò facilita la facile riprogettazione dell'interfaccia utente come vista è implementato in XAML.

Come menzionato prima con MVP, le soluzioni semplici non avrebbero bisogno di schemi di architettura e design, come "Hello World!" è troppo semplice per seguire qualsiasi schema; tuttavia, man mano che vengono introdotte più funzionalità, funzioni e componenti, la complessità dell'applicazione aumenta e aumenta anche la quantità di codice che deve essere gestita.

In sintesi

Dall'avvio dello sviluppo dell'interfaccia utente, i modelli di progettazione stanno diventando sempre più popolari per semplificare il processo di sviluppo, le applicazioni sono più scalabili e facilitano i test più semplici.

Differenza illustrata tra i modelli MVP e MVVM:

  • In entrambe MVP e MVVM, il vista è il punto di accesso all'applicazione
  • Nel MVP, esiste una mappatura uno-a-uno tra il vista e Presentatore, dove in MVVM, la relazione è uno-a-molti tra i vista e ViewModel.
  • MVP viene utilizzato principalmente per Windows Form e applicazioni Windows Phone e MVVM è progettato per Silverlight, WPF, Knockout / AngularJS, ecc.