Cenni preliminari sulle origini di associazione

  • Articolo

Nell'associazione dati, l'oggetto origine di associazione fa riferimento all'oggetto da cui si ottengono i dati. In questo argomento vengono descritti i tipi di oggetto che è possibile utilizzare come origine di associazione.

Nel presente argomento sono contenute le seguenti sezioni.

  • Tipi di origine di associazione
  • Implementazione di una classe come origine di associazione
  • Utilizzo di oggetti interi come origine di associazione
  • Utilizzo di oggetti Collection come origine di associazione
  • Requisiti di autorizzazione in un'associazione dati
  • Argomenti correlati

Tipi di origine di associazione

L'associazione dati Windows Presentation Foundation (WPF) supporta i seguenti tipi di origine di associazione:

Origine di associazione

Descrizione

Oggetti common language runtime (CLR).

È possibile stabilire l'associazione a proprietà pubbliche, proprietà secondarie, nonché indicizzatori di qualsiasi oggetto common language runtime (CLR). La reflection CLR viene utilizzata dal motore di associazione per ottenere i valori delle proprietà. In alternativa, anche gli oggetti che implementano ICustomTypeDescriptor o dispongono di un oggetto TypeDescriptionProvider registrato funzionano con il motore di associazione.

Per ulteriori informazioni sull'implementazione di una classe che può essere utilizzata come origine di associazione, vedere Implementazione di una classe come origine di associazione più avanti in questo argomento.

Oggetti dinamici.

È possibile creare un'associazione a proprietà e indicizzatori disponibili di un oggetto che implementa l'interfaccia IDynamicMetaObjectProvider. Se è possibile accedere al membro nel codice, è possibile creare un'associazione a tale membro. Ad esempio, se un oggetto dinamico consente di accedere a un membro nel codice tramite someObjet.AProperty, è possibile creare un'associazione al membro impostando il percorso di associazione su AProperty.

Oggetti ADO.NET.

È possibile creare un'associazione a oggetti ADO.NET quali DataTable. ADO.NET DataView implementa l'interfaccia IBindingList che fornisce le notifiche delle modifiche per le quali è in ascolto il motore di associazione.

Oggetti XML.

È possibile stabilire l'associazione a XmlNode, XmlDocument o XmlElement ed eseguirvi query XPath. Un modo pratico per accedere a dati XML che rappresentano l'origine di associazione nel markup consiste nell'utilizzare un oggetto XmlDataProvider. Per ulteriori informazioni, vedere Procedura: eseguire l'associazione a dati XML tramite un oggetto XMLDataProvider e query XPath.

È inoltre possibile eseguire l'associazione a un oggetto XElement o XDocument oppure eseguire l'associazione ai risultati delle query eseguite su oggetti di questi tipi mediante LINQ to XML. Un modo pratico di utilizzare LINQ to XML per accedere ai dati XML che rappresentano l'origine di associazione nel markup consiste nell'utilizzare un oggetto ObjectDataProvider. Per ulteriori informazioni, vedere Procedura: eseguire l'associazione ai risultati di una query XDocument, XElement o LINQ to XML.

Oggetti DependencyObject.

È possibile stabilire l'associazione alle proprietà di dipendenza di qualsiasi oggetto DependencyObject. Per un esempio, vedere Procedura: eseguire l'associazione delle proprietà di due controlli.

Implementazione di una classe come origine di associazione

È possibile creare origini di associazione personalizzate. In questa sezione vengono illustrati i concetti necessari per l'implementazione di una classe da utilizzare come origine di associazione.

Invio di notifiche delle modifiche

Se si utilizza l'associazione OneWay o TwoWay per aggiornare l'UI quando le proprietà dell'origine di associazione vengono modificate in modo dinamico, è necessario implementare un meccanismo di notifica adeguato per le proprietà modificate. Il meccanismo consigliato consiste nell'implementare l'interfaccia INotifyPropertyChanged tramite la classe dinamica o tramite CLR. Per ulteriori informazioni, vedere Procedura: implementare notifiche di modifiche alle proprietà.

Se si crea un oggetto CLR che non implementa INotifyPropertyChanged, è necessario configurare un sistema di notifica personalizzato in modo da assicurare che i dati utilizzati in un'associazione siano mantenuti aggiornati. È possibile fornire notifiche delle modifiche tramite il supporto del modello PropertyChanged per ogni proprietà per la quale si desidera impostare tali notifiche. Per supportare questo modello, definire un evento NomeProprietàChanged per ogni proprietà, in cui NomeProprietà rappresenta il nome della proprietà. L'evento viene generato a ogni modifica della proprietà.

Se l'origine di associazione implementa uno di questi meccanismi di notifica, gli aggiornamenti della destinazione vengono eseguiti automaticamente. Se per un motivo qualsiasi l'origine di associazione non fornisce notifiche corrette delle modifiche delle proprietà, è possibile utilizzare il metodo UpdateTarget per aggiornare in modo esplicito la proprietà di destinazione.

Altre caratteristiche

Nell'elenco seguente vengono illustrati altri punti importanti:

  • Se si desidera creare l'oggetto in XAML, la classe deve disporre di un costruttore predefinito. In alcuni linguaggi .NET, ad esempio C#, è possibile che il costruttore predefinito venga creato automaticamente.

  • È necessario che le proprietà utilizzate come proprietà di origine di associazione per un'associazione siano proprietà pubbliche della classe. Non è possibile accedere alle proprietà dell'interfaccia definite in modo esplicito a scopo di associazione, né alle proprietà protette, private, interne o virtuali prive di implementazione di base.

  • Non è possibile stabilire l'associazione a campi pubblici.

  • Il tipo della proprietà dichiarata nella classe è il tipo passato all'associazione. Tuttavia, il tipo utilizzato in ultima analisi dall'associazione dipende dal tipo della proprietà della destinazione di associazione, non della proprietà di origine di associazione. Se è presente una differenza nel tipo, è necessario scrivere un convertitore per gestire la modalità di passaggio iniziale della proprietà personalizzata all'associazione. Per ulteriori informazioni, vedere IValueConverter.

Utilizzo di oggetti interi come origine di associazione

È possibile utilizzare un oggetto intero come origine di associazione. È possibile specificare un'origine di associazione tramite la proprietà Source o DataContext, quindi fornire una dichiarazione di associazione vuota: {Binding}. Tra gli scenari per i quali questa possibilità si rivela utile vi sono l'associazione a oggetti di tipo stringa, l'associazione a oggetti con più proprietà di interesse o l'associazione a oggetti Collection. Per un esempio di associazione a un intero oggetto Collection, vedere Procedura: utilizzare il modello Master-Details con dati gerarchici.

Si noti che può essere necessario applicare logica personalizzata affinché i dati siano significativi per la proprietà di destinazione associata. La logica personalizzata può avere il formato di convertitore personalizzato (se la conversione di tipo predefinita non esiste) o di DataTemplate. Per ulteriori informazioni sui convertitori, vedere la sezione Conversione di dati in Cenni preliminari sull'associazione dati. Per ulteriori informazioni sui modelli di dati, vedere Cenni preliminari sui modelli di dati.

Utilizzo di oggetti Collection come origine di associazione

Spesso l'oggetto che si desidera utilizzare come origine di associazione corrisponde a un insieme di oggetti personalizzati. Ogni oggetto funge da origine per un'istanza di un'associazione ripetuta. Ad esempio se si dispone di un insieme CustomerOrders che include oggetti CustomerOrder, l'applicazione scorrerà l'insieme per determinare il numero di ordini inclusi e i dati contenuti in ciascuno di essi.

È possibile eseguire enumerazioni in qualsiasi insieme che implementa l'interfaccia IEnumerable. Per impostare associazioni dinamiche affinché l'UI venga automaticamente aggiornata in seguito a operazioni di inserimento o eliminazione nell'insieme, tuttavia, è necessario che l'insieme implementi l'interfaccia INotifyCollectionChanged. Questa interfaccia espone un evento che deve essere generato a ogni modifica dell'insieme sottostante.

La classe ObservableCollection<T> rappresenta un'implementazione incorporata di un insieme di dati che espone l'interfaccia INotifyCollectionChanged. I singoli oggetti dati nell'insieme devono soddisfare i requisiti descritti nelle sezioni precedenti. Per un esempio, vedere Procedura: creare ed eseguire l'associazione a una classe ObservableCollection. Prima di implementare un insieme personalizzato, considerare la possibilità di utilizzare ObservableCollection<T> o una delle classi di insiemi esistenti, ad esempio List<T>, Collection<T> e BindingList<T>.

WPF non esegue mai direttamente l'associazione a un insieme. Se si specifica un insieme come origine di associazione, WPF crea effettivamente l'associazione alla visualizzazione predefinita dell'insieme. Per informazioni sulle visualizzazioni predefinite, vedere Cenni preliminari sull'associazione dati.

Se in un scenario avanzato si desidera implementare un insieme personalizzato, è possibile utilizzare l'interfaccia IList. IList fornisce un insieme non generico di oggetti cui è possibile accedere singolarmente in base all'indice, con un possibile miglioramento delle prestazioni.

Requisiti di autorizzazione in un'associazione dati

Quando si crea un'associazione dati, è necessario considerare il livello di attendibilità dell'applicazione. Nella tabella seguente vengono riepilogati i tipi di proprietà ai quali è possibile stabilire l'associazione in un'applicazione eseguita con attendibilità totale o attendibilità parziale:

Tipo proprietà

(tutti i modificatori di accesso)

Proprietà dell'oggetto dinamico

Proprietà dell'oggetto dinamico

Proprietà CLR

Proprietà CLR

Proprietà di dipendenza

Proprietà di dipendenza

Livello di attendibilità

Attendibilità totale

Attendibilità parziale

Attendibilità totale

Attendibilità parziale

Attendibilità totale

Attendibilità parziale

Classe pubblica

Sì

Sì

Sì

Sì

Sì

Sì

Classe non pubblica

Sì

No

Sì

No

Sì

Sì

In questa tabella vengono illustrati punti importanti relativi ai requisiti di autorizzazione per l'associazione dati:

  • Per le proprietà CLR, l'associazione dati funziona purché il motore di associazione sia in grado di accedere alla proprietà di origine di associazione utilizzando la reflection. In caso contrario, viene generato un avviso relativo all'impossibilità di trovare la proprietà e viene utilizzato il valore di fallback o quello predefinito, se disponibile.

  • È possibile creare associazioni alle proprietà degli oggetti dinamici definiti in fase di compilazione o di esecuzione.

  • È sempre possibile stabilire l'associazione alle proprietà di dipendenza.

Il requisito di autorizzazione per l'associazione XML è simile. In un sandbox con attendibilità parziale, si verifica una condizione di errore se XmlDataProvider non dispone delle autorizzazioni per accedere ai dati specificati.

Gli oggetti con un tipo anonimo sono interni. È possibile creare associazioni a proprietà di tipi anonimi solo durante l'esecuzione con attendibilità totale. Per ulteriori informazioni sui tipi anonimi, vedere Tipi anonimi (Guida per programmatori C#) o Anonymous Types (Visual Basic).

Per ulteriori informazioni sulla sicurezza dell'attendibilità parziale, vedere Sicurezza con attendibilità parziale in WPF.

Vedere anche

Attività

Procedura: specificare l'origine di associazione

Riferimenti

ObjectDataProvider

XmlDataProvider

Concetti

Cenni preliminari sull'associazione dati

Cenni preliminari sull'associazione dati WPF con LINQ to XML

Ottimizzazione delle prestazioni: associazione dati

Altre risorse

Procedure relative all'associazione dati