Windows Phone, MVVM

Mi è capitato spesso e volentieri nei miei post di parlare di Model-View-ViewModel (d’ora in poi, semplicemente MVVM), il pattern sicuramente più diffuso nel mondo Silverlight / WPF / Windows Phone / Windows 8. Si tratta di un approccio allo sviluppo che, inizialmente, può spaventare ma che, superato lo scoglio iniziale, da molte soddisfazioni e consente sicuramente di scrivere codice più pulito, più facile da mantenere e da evolvere.

Non ne ho mai parlato però approfonditamente nei miei post: sono un grande sostenitore del pattern MVVM, ma credo anche che sia “pericoloso” inserirlo all’interno di articoli o sessioni (a meno che non sia strettamente collegato all’argomento di cui si vuole parlare); il rischio è che le persone che non conoscono il pattern non siano poi in grado di comprendere anche il messaggio che si vuole veicolare.

Il rischio che però si corre è quello di creare uno scarto tra ciò che viene spiegato e ciò che poi viene utilizzato nel mondo reale: da questa mia considerazione nasce questa serie di post, dedicata al pattern MVVM e a come utilizzarlo nelle applicazioni Windows Phone (e Windows 8). Non mi considero affatto un guru di MVVM, ci sono persone (come Mauro) estremamente più competenti di me: questi post vogliono essere semplicemente una introduzione a MVVM, per farvi scoprire l’approccio che regolarmente utilizzo nelle applicazioni, con lo scopo di darvi l’opportunità di prendere famigliarità con questo pattern e a superare le difficoltà che si possono presentare all’inizio.

Partiamo perciò con qualche concetto teorico, per capire cos’è MVVM e quali sono i vantaggi nell’utilizzarlo.

Perchè MVVM?

Come anticipato all’inizio dell’articolo, è bene precisare che MVVM non è una tecnologia, una libreria o un toolkit, ma è un pattern, ovvero un approccio allo sviluppo, una metodologia per organizzare il proprio codice e che cambia radicalmente il modo in cui siamo abituati a scrivere applicazioni. In rete esistono diverse librerie dedicate a MVVM (come MVVM Light Toolkit, che useremo abbondantamente nei prossimi post), che però non costituiscono il pattern ma semplicemente aiutano ad implementarlo, offrendo una serie di helper e utility.

Gli obiettivi di questo pattern sono analoghi a quelli di tanti altri pattern diffusi nel mondo dello sviluppo, come MVC (Model-View-Controller) e MVP (Model-View-Presenter). Il vantaggio principale è la separazione dei ruoli: quando creiamo applicazioni Windows Phone in maniera tradizionale, nel code behind andiamo a inserire il codice più disparato: logica, interazione con la UI, gestione delle animazioni, ecc. Questa “confusione” rende il codice difficile da mantenere e, soprattutto, poco testabile: se vogliamo scrivere degli unit test per verificare la correttezza del nostro codice siamo costretti a creare un riferimento all’applicazione vera e propria, a simulare le interazioni dell’utente (ad esempio, la pressione di un pulsante) e così via. Il pattern MVVM, invece, consente di separare i ruoli dell’applicazione in tre aspetti ben distinti, che approfondiremo a breve.

Da questa separazione, di conseguenza, emergono gli altri vantaggi nell’adottare questo pattern:

• Il codice è più facile da mantenere, in quanto siamo facilmente in grado di individuare il responsabile di un malfunzionamento, a seconda della tipologia di problema.
• E’ più facile per un designer lavorare sull’interfaccia dell’applicazione, in quanto UI e logica sono separate. In quest’ottica risulta anche molto più semplice, grazie al supporto di Blend per la modalità design, sostituire i servizi reali con dei servizi fittizi, che danno la possibilità al designer di lavorare sulla grafica senza doversi preoccupare di mettere in piedi tutto il necessario per avere dei dati di esempio (pensiamo ad esempio ad applicazioni popolate da servizi web o WCF).

Vediamo ora quali sono le componenti in cui viene suddivisa l’applicazione utilizzando il pattern MVVM, prendendo come esempio di riferimento una semplice applicazione in grado di visualizzare il feed RSS di un sito.

Model

La componente model rappresenta il modello di dati dell’applicazione: concettualmente, sono tutti quei servizi che si occupano di recuperare i dati grezzi che saranno utilizzati. Nella nostra applicazione di riferimento, il model è costituito dalle entità che mappano i contenuti del feed RSS e dai servizi in grado di recuperare dalla rete l’RSS e di trasformarlo in oggetti .NET e quindi in grado di essere manipolati e utilizzati all’interno dell’applicazione.

Il model deve essere completamente “ignorante” di come vengono presentati i dati: nel limite del possibile, come sviluppatori dovremmo essere in grado di riutilizzare il model in un’altra applicazione senza troppi sforzi, proprio perchè deve essere completamente slegato da come i dati vengono presentati.

View

La view è rappresentata dalla UI dell’applicazione, che si occupa di mostrare i dati dell’applicazione in maniera comprensibile all’utente e di gestire tutte le interazioni e le animazioni: la view, al contrario del model, deve essere specifica per l’applicazione a cui stiamo lavorando e, difficilmente, può essere riutilizzata in un’altro prodotto. L’esempio più attuale è il porting di un’applicazione da Windows Phone a Windows 8: la UI, per forza di cose, sarà diversa, dato che le due piattaforme, pur condividendo lo stile Metro, prevedono paradigmi e modalità di interazione differenti.

Nel contesto di un’applicazione Windows Phone o Windows 8, la view è rappresentata dai file XAML che definiscono l’interfaccia. In linea di massima, l’approccio MVVM porta ad avere il code behind praticamente vuoto, in quanto la logica dell’applicazione è slegata dalla view: tipicamente, l’unica logica che il pattern ammette nel code behind è quella relativa ad aspetti legati alla UI, come l’avvio di animazioni.

ViewModel

Il ViewModel è ciò che fa da collante tra la view e il model: si occupa di prendere i dati grezzi restituiti dal model e di prepararli affinchè la view sia in grado di visualizzarli. Ciò che rende possibile il collegamento tra i due mondi è il binding: tutte le proprietà del ViewModel vengono collegate all’interfaccia sfruttando il binding del mondo XAML, ovverò la possibilità di creare un canale di comunicazione tra l’interfaccia e gli oggetti nel codice. L’altra caratteristica fondamentale che deve avere il ViewModel è il supporto all’interfaccia INotifyPropertyChanged: in questo modo, ogni volta che una delle proprietà viene modificata i controlli della UI che sono in binding con la stessa sono automaticamente aggiornati per mostrare il nuovo stato.

In conclusione

In questo primo post abbiamo introdotto il pattern MVVM e ne abbiamo definito i principali aspetti teorici: nei prossimi post scenderemo un po’ più in dettaglio e vedremo come realizzare, nel concerto, il nostro feed reader sfruttando i concetti appresi.

This entry was posted on Wednesday, 25 July, 2012 and is filed under Windows Phone Tutorials . You can follow any responses to this entry through here . You can leave a response.