Di recente per motivi di lavoro ho dovuto scrivere una applicazione in WPF/Silverlight. Per costruire la mia applicazione e per rimanere fedele al principio architetturale della stratificazione a livelli ho cercato un pattern adatto..
Come prima cosa ho cercato conforto nel pattern MVC.Per chi non ne ha mai sentito parlare l'MVC è un pattern architetturale che isola in modo soddisfacente la logica dell'interfaccia utente dalla logica di business. In tal modo risulta facile apportare modifiche in una delle due parti senza che questa modifica si ripercuota su altre parti. La parola MVC ricalca la struttura che è composta da tre componenti:
-
Model: Rappresenta il modello dei dati
-
View:Rappresenta la vera interfaccia utente con i vari controlli visuali.
-
Controller: si occupa di gestire la richiesta e di coordinarne la logica di esecuzione utilizzando il Model e selezionando la View da associare per la risposta.
L’utente interagisce con la View che comunica le chiamate al controller che a sua volta comunica con il model che si occupa di apportare un aggiornamento nella view. Di seguito lo schema di funzionamento dei tre moduli.
Questo tipo di pattern non lavora bene con le le interfacce utente ottenute con la programmazione dichiarativa (cioè XAML) in quanto vi sono moltissimi costrutti di programmazione ,soprattuto nel contesto di associazione dati, che consentono di risparmiare un sacco di codice. Ma il fattore principale riguarda il fatto che tutto ciò che in precedenza doveva essere programmato in C # è ora possibile farlo usando XAML attraverso trigger o eventi.
Dopo aver compreso che non potevo utilizzare il pattern MVC ho provato ad applicare il pattern MVP in cui viene sostituito al pattern precedente il controller con un altro modulo che è il presenter e quindi si ha:
-
Model: Rappresenta il modello dei dati
-
View:Rappresenta la vera interfaccia utente con i vari controlli visuali.
-
Presenter: è responsabile della gestione dello stato delle View e della loro inizializzazione.
Anche questo pattern però non si adatta al modo di lavorare di WPF/Silverlight in quanto lo stesso XAML prevede già la gestione degli stati senza dover avere un modulo che se ne occupi.
Quindi vi è la necessità di avere un altro pattern che in qualche modo è il mix del pattern MVC e del pattern MVP. Questo pattern è MVVM (Model-View-ViewModel) che come gli altri pattern visti sopra ha lo scopo di disaccoppiare il più possibile per arrivare al concettto di “Separation of Concerns”. Il MVVM è composto dalle seguenti componenti:
- Model: è responsabile di esporre i dati in modo che sia facilmente consumabile da WPF. Si deve implementare INotifyPropertyChanged o INotifyCollectionChanged a seconda dei casi.
-
View: è l'interfaccia utente reale. Il processo che usiamo è quello di impostare il DataContext all’interno del ViewModel di una View in questo modo è reso più facile usare il Binding attraverso il ViewModel. Idealmente, la View può essere implementata esclusivamente con Xaml senza usare il code-behind e questo proprio perché si possono usare le proprietà di una classe viewmodel.
-
ViewModel: è un modello per una View in una applicazione. Questo componente esponei dati relativi (proprietà) alla View e non solo ma espone anche i comportamenti (metodi) delle View che di solito vengono richiamati da dei comandi. Il modello è abbastanza specifico per una certa View all’intenro di una applicazionevi. Poiché queste classi sono separate da quello della UI sono relativamente semplici da applicare ai test di unità.
Di seguito vediamo la rappresentazione grafica del pattern:
Quindi se andiamo ad analizzare i riferimenti che legano i vari moduli tra le varie architetture MVC,MVP.MVVM abbiamo il seguente schema:
E' Possibile trovare un esempio pratico dell'MVVM qui.