Windows Presentation Foundation è un framework che sta acquisendo ormai un ruolo importante e Microsoft stessa lo adotta per strumenti quali Microsoft Expression e il prossimo Microsoft Visual Studio 10. E' chiaro quindi che questa tecnologia non la si può più ignorare e tra i vari aspetti da affrontare, oltre alle funzionionalità grafiche, gli Style, i Template e tutti i controlli, va affrontato anche come architetturare un'applicazione che fa uso di WPF. Si può dire che la maggior parte del materiale che si trovi su questa tecnologia sia più rivolto ad un grafico, poiché la linea che pone il confine tra ciò che fanno uno sviluppatore e un grafico si sposta di più sullo sviluppo di codice da parte del primo.

In questo articolo si vuole affrontare un pattern, un modo di porre il codice che sta prendendo molto piede, e fatto su misura per WPF e gli strumenti che mette a disposizione. Il nome Model-View-ViewModel (MVVM) è un ibrido tra MVC e MVP e sfrutta quelle caratteristiche di WPF che permettono di restare astratti dall'interfaccia grafica, il cui scopo è:

• favorire al massimo il paradigma di separazione del codice dall'interfaccia grafica. Lo sviluppatore non conosce l'interfaccia e mette a disposizione una serie di informazioni e funzionalità che il grafico sfrutta;
• maggiore capacità di riutilizzo del codice. Il codice in un'architettura MVVM può, con piccole accortezze, essere riutilizzato tranquillamente in un'applicazione Silverlight;
• aumentare la superficie di testing così da poter testare, con gli strumenti messi a disposizione da Visual Studio, praticamente ogni strato dell'applicazione, lasciando solo la parte grafica che poggia però su controlli già testati da Microsoft.

Questo terzo punto può per essere per alcuni nuovo oppure conosciuto, ma trascurato fino ad ora. Purtroppo gli sviluppatori (anche l'autore dell'articolo stesso) che si basano su tecnologie Microsoft si sono abituati male a sviluppare, fin dai tempi di Visual Basic, e non è nel loro DNA preoccuparsi della tematica del testing, laddove invece in altri ambienti o linguaggi è un must e garantisce molto di più la manutenzione nel tempo di un software e l'individuazione di eventuali bug.

Il pattern prevede di dividere in tre parti la parte di presentazione di un'applicazione:

• Model: le entità che fanno da repository delle informazioni;
• View: il markup XAML del quale se ne dovrebbe occupare il grafico;
• ViewModel: l'intermediario tra il Model e il View che espone le funzionalità adattandosi alle caratteristiche di astrazione WPF/Silverlight;

Ovviamente quest'architettura è una proposta ed è sicuramente sottoponibile a varianti, può essere adottata in parte o totalmente scartata, ma poiché sfruttata dal team stesso di Microsoft Expression si consiglia di tenerla in considerazione.

Il Domain Model

Supponendo di voler sviluppare un semplice forum che presenti una lista di Thread i quali a loro volta hanno una lista di Post, si procede come ormai si è soliti fare preparando le classi che rappresentano il proprio Model e permettono di interrogare le informazioni. Questo può essere semplicemente un accesso diretto alle informazioni, usando LINQ to Sql, oppure di un'architettura 3-tier lo strato di Business che permette di validare ciò che si interroga e passare il lavoro effettivo al Data Access Layer che effettua poi le query su database. O ancora potrebbe sfruttare un approccio SOA e lavorare in modo disconesso esponendo dei servizi. Le classi che il consumer ricrea e il Service Agent che permette di consumare i servizi sono il punto d'accesso al repository alle informazioni.

Nel nostro esempio questo primo strato è una semplice classe statica che crea a runtime delle entità di esempio, del quale è sufficiente vederne il diagramma.

Poiché questo strato può essere considerato quello di business di una soluzione 3-tier, valgono tutte le regole e le funzionalità che si possono solitamente aggiungere. Le entità possono per esempio implementare IDataErrorInfo o INotifyPropertyChanged per la validazione delle proprietà e per la notifica di quando esse cambiano. Entrambe le interfacce sono infatti presenti sin dal .NET Framework 1.0 e sono sfruttabili dal motore di Binding delle WinForm. Nel nostro caso questo non avviene, ma si è preferito semplicemente usare il Domain come un repository.