SUE AGILE MVVM (Italian)
0 likes280 views
Il documento descrive l'implementazione del pattern architetturale MVVM nella piattaforma sue-agile, evidenziando la separazione tra model, view e viewmodel per una gestione efficiente dei dati e della visualizzazione. Il viewmodel funge da intermediario tra la view e il model, facilitando il data binding e permettendo la modifica isolata di componenti senza influenzare il resto del sistema. Si menzionano anche le tecnologie utilizzate, come C#, TypeScript e HTML5, nonché l'importanza di KnockoutJS per il data binding.
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.