Data binding
Il lavoro più pesante che fanno le applicazioni, specie quelle per uso gestionale, è prendere i dati da qualche parte, mostrarli sul video in modo comprensibile, accettare gli input dell’utente, validare con scrupolosa e maniacale precisione i dati inseriti e trasferirli in qualche struttura di memorizzazione permanente. Lungo la strada, spesso i dati sono trasformati in vario modo.
Chi scrive applicazioni, sa che passerà quattro quinti del tempo di sviluppo a occuparsi dell’interfaccia utente e di tutti i problemi di trasformazione e validazione dei dati. I problemi tecnologici di un’applicazione, per esempio la connessione con servizi remoti o il pilotaggio di dispositivi particolari, come lettori di carte di credito, sono di norma più facili da risolvere, anche se richiedono studio intenso e la soluzione di problemi di elevata complessità . Sono, infatti, problemi in cui la complessità è elevata e localizzata, che si risolvono in fasi aperte e chiuse nello spazio di una settimana.
Non stupisce, allora, che Xaml sia dotato di una ricca selezione di strumenti per regolare il passaggio dei dati in modo automatico e ordinato fra le variabili di programma e l’interfaccia utente. La chiave del meccanismo, sta nel concetto di binding, cioè il legame, fra una variabile di programma e qualche elemento di interfaccia utente. Il binding viene specificato in modo dichiarativo nel file Xaml e soddisfatto a run time. Questo vuol dire che il sistema riesce a creare un legame fra una variabile e una proprietà di un elemento di interfaccia in modo dinamico.
Si tratta di un meccanismo facile da usare, ma che pone problemi tecnologici non lievi al framework. Per esempio, nel file Xaml viene specificato il nome di una variabile, che deve essere risolto con un link dinamico a run time usando la reflection, cioè la capacità del codice di convertire il nome di una variabile in un indirizzo di programma durante l’esecuzione, sfruttando le tabelle create dal linker e conservate nella struttura dell’eseguibile. Quando il sistema ha individuato la variabile collegata allo stato di un elemento di interfaccia grazie alla reflection deve collegarla con l’elemento richiesto, per esempio il valore di un campo di testo o lo stato di una checkbox. Durante il percorso può anche essere necessaria una conversione, per esempio fra un valore e un colore. Tutti questi problemi sono risolti dalla soluzione Microsoft, in modo che accada proprio quello che il programmatore si aspetta nelle diverse situazioni. Per esempio si può inserire un ValueConverter sul percorso di un binding. Il Data Binding può avvenire in diverse direzioni, in accordo con diverse esigenze applicative. Il trasporto dei dati può avvenire dallo stato del codice verso l’interfaccia, da questa verso i modelli applicativi, o in entrambe le direzioni, per esempio in una transazione di modifica.
Dal punto di vista di un modello di programmazione tradizionale, per esempio Visual Basic, è come avere la possibilità di creare automaticamente gestori dei dati da inserire nel caricamento dell’interfaccia (Form.OnLoad) e al momento in cui termina l’input su un controllo visuale (Control.LostFocus). Questi gestori di dati sono abbastanza flessibili da consentire l’inserimento di un modulo di trasformazione dei dati con cui possiamo, per esempio, trasformare un colore in un indice in una listbox e viceversa, oppure trasformare una data in un formato di visualizzazione diverso da quello che abbiamo nel database.
Il meccanismo del data binding consente il collegamento con variabili, proprietà di oggetti, interrogazioni XQuery su dataset xml e recordset estratti dal database.
Non siamo limitati a operazioni scalari: possiamo anche fare il binding di Collection con un array di controlli, per esempio per trasformare un recordset in una successione di controlli utente. Per fare un esempio, potremmo associare una lista di film in programmazione in una multisala in una serie di controlli utente composti da locandina, titolo, trama e comandi per l’acquisto biglietti.
Tanti pro, pochi contro
Con questa breve introduzione, crediamo di avere dimostrato che ci sono ottime ragioni per considerare l’utilizzo di Xaml, una chiave dello sviluppo up to date con Windows in tutte le versioni, dal cellulare, al tablet, al computer. Consideriamo anche che la recente apertura del codice di .net darà alla piattaforma la possibilità di migrare su altri sistemi.
Quello che offre Xaml non è solo, come abbiamo visto, la comodità e l’economia di codice, grazie ai binding, ma anche la razionalizzazione del modello applicativo con una buona separazione fra il codice di interfaccia e il codice legato alle regole di business, adottando uno dei numerosi framework Mvvm (model, view, viewmodel). Infine, una motivazione interessante per passare sul nuovo modello applicativo, lasciando il territorio familiare di WinForms, è la possibilità di entrare in nuovi ambiti, sviluppando contemporaneamente per le diverse versioni di Windows, anche i tablet economici WinRT con processore Arm, e per Windows Phone.
Michele Costabile