SUE AGILE MVVM (Italian)

1. 3.c.6 Pattern MVVM
Per fornire alla piattaforma SUE-Agile una adeguata struttura ed organanizzazione di componenti si è scelto
di utilizzare il pattern architetturale “Model View View-Model”.
Esso consiste nella separazione degli aspetti dell’applicazione in tre componenti:
• Model
• View
• ViewModel
Come si deduce facilmente dalla figura precedente 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, mentre 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 e
viceversa.
Il ViewModel (VM) può essere immaginato come un’astrazione della view, ma nello stesso tempo è anche una
specializzazione del model che la view utilizza per il data binding. Il VM è particolarmente utile quando il Model
è complesso, o è già esistente e non si può modificare, oppure quando i tipi di dato del model non sono
facilmente collegabili alla view.
Quando l’utente interagisce con la View, instantaneamente la variazione di stato è comunicata al ViewModel
(grazie al Data-Binding) e come risposta al cambio di stato o all’attivazione di un metodo il ViewModel “agisce”
tramite il Model e aggiorna il proprio stato. Il nuovo stato del ViewModel si riflette poi sulla View.
E’ fondamentale il fatto che il ViewModel mantenga nel proprio stato non solo le informazioni recuperate
attraverso il Model, ma anche lo stato attuale della visualizzazione: ciò gli consente di essere del tutto
disaccoppiato dalla View.
Un modo per visualizzare il concetto è pensare alle applicazioni che fanno uso di tale pattern come composte
da un albero di ViewModel, ciascuno responsabile di una particolare "zona" dell'interfaccia utente, che realizzi
nel suo insieme una sorta di macchina a stati: ogni volta che l'utente sollecita l'applicazione, e quindi

2. indirettamente la "macchina", quest'ultima reagisce, cambiando il proprio stato ed eseguendo sotto il proprio
controllo le operazioni di dominio business.
In questa visione, la View si riduce ad un "vetro" attraverso il quale l'utente osserva il funzionamento della
"macchina".
Ciò consente di ottenere facilmente la separazione del comportamento dell'applicazione dal suo "Look &
Feel"; questo è estremamente vantaggioso in scenari di sviluppo (ultimamente sempre più diffusi) in cui gli
aspetti di User Experience sono curati da figure con precise competenze, diverse da quelle necessarie per lo
sviluppo e la codifica.
Per facilitare questa separazione, il ViewModel deve essere progettato in termini il più possibile astratti; anche
per questo motivo è preferibile evitare dipendenze dirette alla View stessa, oppure verso componenti specifici
della tecnologia di UI. E' piuttosto comune per le applicazioni moderne fare uso della cosiddetta UI
composition, ovvero della capacità di comporre l'interfaccia utente mediante la creazione dinamica di diversi
parti più piccole, spesso coordinate, collocate all'interno di opportune zone di una "impalcatura" principale,
detta shell. Un classico esempio (probabilmente tra i più complessi) di questa tecnica è la UI di Visual Studio,
composta da una numerosa serie di pannelli, toolbar e finestre di documento, completamente personalizzabile
dall'utente ed estendibile con nuovi componenti forniti mediante plugin.
Oltre all'aspetto puramente "visuale", tuttavia, la UI Composition richiede la presenza di qualche tipo di
infrastruttura che regoli e diriga il ciclo di vita (creazione, inizializzazione, attivazione, disattivazione, rilascio)
delle varie porzioni di schermo.
Il pattern MVVM non prescrive una linea precisa per questi aspetti; le diverse implementazioni, comunque,
sono suddivise in due gruppi principali:
 View-First: il processo di composizione è guidato e sollecitato dalla View; quest'ultima, cioè, stabilisce
quali parti debbano essere composte e in quale zona della shell siano visualizzate. Questa
impostazione richiede che i ViewModel associati a ciascuna parte della View siano istanziati e collegati
in fase successiva;
 Model-First: la composizione è gestita istanziando prima di tutto il ViewModel e collegando
successivamente la View corrispondente. In questa impostazione, che ritengo più naturale ed in linea
con la filosofia del MVVM, la composizione avviene prima di tutto a livello del ViewModel, mediante la
creazione (anche dinamica) di un "albero" delle varie parti; alla View è lasciato il compito di
rappresentare questo albero e le sue variazioni utilizzando gli usuali meccanismi di binding e
templating.
Come anticipato nei paragrafi precedenti Il SUE-Agile è stato sviluppato all’interno di un ambiente di tipo
.NET.Si è quindi fatto uso del linguaggio C# nella parte che si interfaccia con il livello dei dati, mentre per la
codifica del View-Model si è deciso di utilizzare lo script-language “Typescript”, le cui principali caratteristiche
sono meglio delineate in un altro paragrafo del documento. Per la View sono state invece sfruttate le
potenzialità e le novità introdotte dal linguaggio di mark-up HTML5. Importante per il collegamento tra questi
ultimi due componenti è stata senza dubbio la libreria KnockoutJs che ha permesso di implementare in
maniera semplice ed ottimale i meccanismi di data-binding.

3. Uno dei maggiori vantaggi derivanti dall’adozione di tale pattern è senza dubbio la possibilità di modificare
singole parti del codice senza influire sulle altre, garantendo quindi una manutenibilità del migliore dello stesso
e semplificando notevolmente la fase di test.