WPF e il pattern MVVM

MVVM: in pratica, breve introduzione alla teoria

Con l’avvento della programmazione Object Oriented e di metodologie sempre più sofisticate per la costruzione di Interfacce Utente (UI), si è avvertita la necessità di sviluppare pattern che permettessero di “tenere separati i livelli“. Alla base di questi approcci si pone l’obiettivo di permettere al modello, alla “logica” e alla UI di vivere di vita propria ed in modo del tutto indipendente gli uni dagli altri. Attenzione a non travisare il concetto visto che si sta parlando di indipendenza funzionale e non applicativa: significa che se si dovesse cambiare, ad esempio, il modello con uno “equivalente” dal punto di vista dei tipi l’applicazione, se ben strutturata, dovrebbe continuare a funzionare senza batter ciglio. Segue questo approccio il già consolidato MVC, Model View Controller, ormai un must nelle applicazioni Enterprise (Java JSF e ASP .NET).

Argomento di questa breve introduzione vuol essere il pattern che va sotto il nome di MVVM, Model View ViewModel, sempre più usato nello sviluppo di applicazioni WPF, Silverlight, Windows Phone e Windows 8 visto che, in particolare tra le ultime due piattaforme citate, permette, usando una specifica implementazione, di “riusare” gran parte del codice.

Si è già detto che MVVM in sé non è una libreria e né tantomeno un helper, ma bensì un pattern o, se preferite, un approccio allo sviluppo di applicazioni. Fu introdotto per la prima volta da John Gossman durante lo sviluppo di WPF ed è un diretto discendente del pattern Presentation Model di Martin Fowler.

Consiste nella separazione degli aspetti della nostra applicazione in tre componenti: •Model •View •ViewModel

permettendoci di evitare di mescolare il codice che fornisce la logica a quello che gestisce la UI.

Le componenti

Il Model rappresenta il punto di accesso ai dati. Trattasi di una o più classi che leggono dati dal DB, oppure da un servizio Web di qualsivoglia natura.

La View rappresenta la vista dell’applicazione, l’interfaccia grafica che mostrerà i dati.

Il ViewModel è il punto di incontro tra la View e il Model: i dati ricevuti da quest’ultimo sono elaborati per essere presentati e passati alla View.

Il fulcro del funzionamento di questo pattern è la creazione di un componente, il ViewModel appunto, che rappresenta tutte le informazioni e i comportamenti della corrispondente View. La View si limita infatti, a visualizzare graficamente quanto esposto dal ViewModel, a riflettere in esso i suoi cambi di stato oppure ad attivarne dei comportamenti.

Come interagiscono i vari livelli? 1.L’utente interagisce con la View. 2.La variazione di stato è comunicata al ViewModel (Binding), oppure tramite Command è attivato un metodo. 3.Come risposta al cambio di stato o all’attivazione di un metodo il ViewModel “fa qualcosa” sul Model e aggiorna il proprio stato. 4.Il nuovo stato del ViewModel si riflette sulla View.

E’ da sottolineare il fatto che il ViewModel mantiene nel proprio stato non solo le informazioni recuparate attraverso il Model, ma anche lo stato attuale della visualizzazione: ciò gli consente di essere del tutto disaccoppiato dalla View. Inoltre il processo step-by-step descritto in precedenza risulta essere un “two way”, funziona cioè in entrambe le direzioni.

In pratica: Binding e INotifyPropertyChanged in MVVM Light Toolkit

Essendo un pattern, MVVM, non necessita di alcuna libreria in particolare per essere implementato: né esistono però alcune già pronte che possono semplificarci la vita. La più famosa è senza dubbio MVVM Light Toolkit.

Riassumiamone i meccanismi: •Tutte le interazioni con la UI sono gestite dal ViewModel, che opera da Data Context della View e le proprietà esposte dal ViewModel sono collegate alla UI via Binding. •Implementando l’interfaccia INotifyPropertyChanged, ogni volta che una proprietà del ViewModel cambia, l’interfaccia si aggiorna al nuovo valore e viceversa.

In particolare: •Il ViewModel è sostanzialmente una classe che implementa l’interfaccia INotifyPropertyChanged. •Per notificare ad un controllo che la proprietà in binding è cambiata si scatena un evento. Per semplificarci la vita il Light Toolkit ci mette a disposizione il metodo RaisePropertyChanged(..) per non creare di volta in volta un evento personalizzato. •E’ necessario ricordare che il ViewModel non sa nulla del funzionamento del Model. La cosa importante è che sia mappato sul tipo di dato.

•Binding con nome esplicito e modalità TwoWay per permettere un’interazione bidirezionale tra View e ViewModel.

•Il Model non sa nulla della vista e del modo in cui verranno rappresentati i dati.

In pratica: ICommand perché di non solo dati si vive

L’applicazione è in genere e soprattutto interazione con l’utente: nel modello classico questo aspetto è rappresentato per mezzo degli eventi. Quest’ultimi però fanno poco MVVM visto che ci constringerebbero a mischiare un pò le cose e a scrivere del codice nel code-behind della View. Proprio per evitare ciò ci vengono in soccorso i Command.

Ogni interazione è un comando (normale funzione) che può essere espresso tramite Binding grazie alla proprietà Command esposta da tutti i controlli che prevedono interazione. Il comando da invocare deve essere di tipo ICommand e dichiarato nel ViewModel.

Il Light Toolkit ci mette a disposizione la classe RelayCommand, così come avveniva per gli eventi, per non scrivere di volta in volta delle funzioni personalizzate.

Che vantaggi ci presenta questo approccio?

•Codice più facile da mantenere, vista la distinzione tra i tre aspetti •Testabilità: lo Unit Testing è una pratica fondamentale nell’ambito dello sviluppo del software. Il fatto che in MVVM le componenti siano “separate” contribuisce alla progettazione di unità di test efficaci. •Blendability: vista la separazione tra logica e UI, per un designer che usa Blend è più facile lavorare sull’aspetto “esteriore” senza preoccuparsi di altro.