Dipendenza da DependencyObject e DependencyProperty

Question

Sto costruendo un'applicazione Silverlight e uno dei miei avvertimenti dell'ultima volta è stato che se avessi bisogno di qualcosa fatto esattamente nel modo Silverlight / WPF avresti bisogno di modellare i tuoi oggetti come DependecyObject e usare DependencyProperty (ies)

Trovo che questo modello sia piuttosto ingombrante, che richiede campi statici e inizializzatori in metà delle classi che uso, quindi è una buona idea usare il buon vecchio evento-driven (modello di osservatore?) al posto di DependencyObject?

Sto mirando a minimizzare il gonfiamento del codice e le piastre della caldaia (le odio) e vorrei davvero sapere se qualcuno con esperienza in Silverlight / WPF ha qualche suggerimento / tecnica per limitare al minimo l'utilizzo di DependencyObject e DependencyProperty?

È una buona idea?

Answer 1

In realtà, in Silverlight non puoi ereditare DependencyObjects, quindi dovresti (e devi) implementare INotifyPropertyChanged invece.

L'implementazione di INotifyPropertyChanged presenta molti vantaggi rispetto a DependencyObjects (abbrevierò questo DO per renderlo più semplice) e l'utilizzo di DependencyProperties (DPs):

• Questo è più leggero
• Ti consente maggiore libertà nella modellazione dei tuoi oggetti
• Può essere serializzato facilmente
• Puoi generare l'evento quando vuoi, il che può essere utile in alcuni scenari, ad esempio quando vuoi raggruppare più modifiche in una sola operazione dell'interfaccia utente o quando devi generare l'evento anche se i dati non lo hanno fatto modifica (per forzare il ridisegno ...)

D'altro canto, ereditare DO in WPF presenta i seguenti vantaggi:

• Più facile da implementare soprattutto per i principianti.
• Ottieni un meccanismo di callback (quasi) gratuito, che ti consente di essere avvisato quando il valore della proprietà cambia
• Ottieni un meccanismo di coercizione che ti consente di definire le regole per il valore massimo, minimo e attuale della proprietà.

Ci sono altre considerazioni, ma queste sono le principali.

Penso che il consenso generale sia che i DP sono ottimi per i controlli (e puoi implementare un CustomControl con DP personalizzati anche in Silverlight), ma per gli oggetti dati dovresti piuttosto implementare INotifyPropertyChanged.

HTH, Laurent

Answer 2

Dipende davvero da quali oggetti ti riferisci. Se l'oggetto è destinato a stare nell'albero XAML, è meglio usare DependencyProperties (e quindi ereditare DependencyObject - che fanno tutti gli UIElement) per consentire tutti i benefici che offrono DependencyProperties (essendo animabile, vincolante, eredità figlio automatica opzionale, ecc.). Consiglio vivamente di leggere la Panoramica di MSDN su DependencyProperties se non hai " t già.

Se l'oggetto è un'entità dati (ad es. si stanno vincolando i suoi valori A qualcosa nella struttura XAML), non è necessario ereditare da DependencyObject. Se le proprietà sull'oggetto sono in lettura-scrittura, è possibile che si desideri implementare INotifyPropertyChanged , che consentirà ai binding di aggiornarsi automaticamente quando il valore cambia.

Answer 3

Concordo con Richard sul fatto che dipende dallo scopo della tua classe, ma come nota sembra che PUOI ereditare da DependencyObject direttamente in Silverlight 2.0 Release, senza dover ereditare da UIElement o UserControl. Almeno, lo sto facendo nella mia app (SilverLight 2.0 RTW).

System.Windows.DependencyObject on MSDN

  

È non tipico derivare direttamente da DependencyObject per la maggior parte degli scenari. Invece potresti derivare da un controllo specifico, da una delle classi base di controllo (ContentControl; Control; ItemsControl), da FrameworkElement o da classi non di controllo che ancora partecipano all'interfaccia utente come Panel o Grid. Derivare da DependencyObject potrebbe essere appropriato se si sta definendo un oggetto di archiviazione dati o business in cui si desidera che le proprietà di dipendenza siano attive o se si sta creando una classe di supporto del servizio che sarà proprietaria delle proprietà associate.

HTH