Per concludere la carrellata di post relativi a Longhorn (sospesa per causa di forza maggiore), in vista del prossimo evento di ASPItalia in cui si parlerà di XAML e Avalon, direi che è doveroso spendere qualche parola sul data binding, ovvero l'associazione tra elementi della UI con le informazioni provenienti dalle sorgenti dati.

Oggi siamo abituati a considerare il data binding come un meccanismo fondamentalmente unidirezionale. Questo significa che in generale le informazioni vanno dal data source al controllo della UI oppure, in alternativa, i dati possono venire salvati nel data source. In ogni caso oggi non si parla di data binding bidirezionale.

Rispetto all'approccio per così dire tradizionale, i meccanismi di data binding tra sorgente dati e controlli dell'interfaccia utente in Longhorn vengono estesi e potenziati. Il data binding può essere anche (ma non solo) bidirezionale, nel senso che viene supportato contemporaneamente il flusso in entrambe le direzioni, dalla sorgente al controllo, dal controllo alla sorgente. Parallelamente il data binding può essere statico oppure dinamico (un meccanismo che in un certo senso a me ricorda il concetto di cursore in ADO). Ma andiamo per ordine.

Tipi di data binding

DATA BINDING ONE-TIME
In questo caso, in base al data source e al percorso specificato, il runtime recupera il valore dalla sorgente e imposta la proprietà target. In seguito a questo, di solito non avviene assolutamente più nulla nel caso in cui o il valore sorgente o la proprietà target dovessero cambiare.

DATA BINDING ONE-WAY
Nel caso one-way, il runtime recupera il valore della sorgente e imposta la proprietà target, proprio come prima. Ma la differenza sta nel fatto che, qualora il valore sorgente dovesse essere per qualche motivo cambiato, il binding propaga la modifica dalla sorgente alla proprietà target.

DATA BINDING TWO-WAY
E' il data binding bidirezionale di cui si parlava prima. Il runtime recupera il valore della sorgente e imposta la proprietà target, proprio come nei primi due casi. Qualora o il valore sorgente o la proprietà target dovessero cambiare, il binding propaga la modifica o in un senso o nell'altro, a seconda dei casi. Questo è il tipo di data binding predefinito.

La classe in Avalon che rappresenta il data binding è MSAvalon.Data.Bind. Questa classe è caratterizzata da una serie di proprietà utili allo scopo:

• Path: indica la proprietà o il valore sorgente.
• BindType: specifica il tipo di binding secondo quanto detto in precedenza (OneTime, OneWay, TwoWay).
• UpdateType: proprietà valida con il binding two-way, nel caso di propagazione delle modifiche dalla proprietà target alla sorgente. Può valere Immediate (ovvero subito), OnLostFocus (ovvero quando il controllo perde il focus) oppure Explicit (ovvero in maniera esplicita quando viene invocato l'oggetto bind).
• Source: specifica il data item sorgente.
• Transformer: permette di assegnare un oggetto che implementa l'interfaccia IDataTransformer (metodi Transform e InverseTrasform) che consente di trasformare il valore in entrata in un nuovo valore in uscita; si tratta di una specie di mappa di trasformazione che accetta in input un Object e restituisce un Object, nei due sensi.
• Culture: consente di specificare un CultureInfo.
• BindFlags: permette di un impostare un flag che informa dell'avvenuto trasferimento dei dati.

Per rendere più chiari i concetti passerei ad un paio di esempi, che sono molto di più di tante parole.

CODICE C#

using MSAvalon.Data;
Bind dataBinding = new Bind(sourcePath, bindType, dataSource, updateType);
element.SetBinding(property, binding);
  

XAML

<DockPanel>
  <DockPanel.Resources>
    <SqlDataSource def:Name="mySource" ConnectionString="..." SelectCommand="SELECT * FROM Table" />
  </DockPanel.Resources>
  <SimpleText Text="*Bind(Path=Field;BindType=OneWay)" />
</DockPanel>
  

Io mi fermo qua! Tutto il resto (e molto di più) lo lascio dire a Ricciolo e a Daniele al WDD del prossimo 28 gennaio.