Enterprise design: MVC, MVP e MVVM - parte 4

Oggi si parla di teoria e in particolare di pattern architetturali. Nella prossima puntata inizierò ad analizzare il progetto realizzato sulla base dei principi esposti nella parte 3 e in questo post.

I pattern che vedremo sono il Model-View-Controller, il pattern Model-View-Presenter e la versione modificata da Microsoft, il Model-View-ViewModel

Partiamo dal pattern MVC (Model View Controller)

Model: il model rappresenta i dati che le view visualizzano o modificano. Si può immaginare come una serie di metodi che forniscono alla View i dati da visualizzare e una serie di metodi che il Controller chiama per modificare i dati su richiesta della View.
View: è la parte che l'utente vede e su cui l'utente compie azioni. La View raccoglie i dati provenienti dal Model e indirizza al Controller le azioni fatte dall'utente.
Controller: è la parte che coordina le interazioni tra View e Model. Semplificando raccoglie le azioni compiute sulla View e agisce sul Model perchè vengano restituite le giuste informazioni.

Il secondo pattern è il MVP (Model View Presenter)

Abbiamo sempre un'architettura basata su 3 livelli ma cambiano le dipendenze. Non abbiamo più il Controller ma uno strato definito Presenter che si occupa di chiedere al Model i dati che poi presenterà alla View adattandoli alle necessità della visualizzazione. La grande differenza è che nel modello MVC il Controller non risponde al View ma chiede al Model di farlo. Nel modello MVP la View comunica esclusivamente con il Presenter ed è assolutamente all'oscuro di cosa ci sia oltre il Presenter.

L'ultimo pattern è il MVVM (Model View ViewModel)

Questo modello nasce dalla constatazione che se esistono meccanismi di databinding bidirezionale allora applicare i modelli precedenti che richiedono la rinuncia all'utilizzo del databinding diventa improduttivo. Il MVVM deriva dal modello MVP, in particolare crea un nuovo modello differente dal modello di dominio per le proprietà che lo adattano alle necessità della View. Il Presenter che possiamo rinominare ViewModel quindi sarà costituito in parte da proprietà del Model e in parte da proprietà derivanti dalla View. Il collegamento ai data è delegato ai meccanismi di databinding.