2009-06-26 12 views
5

Ho difficoltà a capire i buoni motivi della proprietà di dipendenza. Perché la proprietà "Testo" di System.Controls.TextBox è una proprietà di dipendenza e non una proprietà normale? Quali benefici serve essere una proprietà di dipendenza?Proprietà dipendenza Utilizza in WPF

Una delle cose che sto cercando di realizzare è aggiungere una proprietà ValidationRules al mio UserControl che conterrà altre regole di validazione. Come qui:

<customControls:RequiredTextBox.ValidationRules> 
         <validators:NotNullOrEmptyValidationRule ErrorMessage="FirstName cannot be null or empty"/> 
        </customControls:RequiredTextBox.ValidationRules> 

Il problema è che io non sono sicuro se la proprietà ValidationRules dovrebbe essere DependencyProperty o semplicemente una proprietà normale.

Il codice di cui sopra dà il seguente errore:

{"Cannot add element to 'ValidationRules'; the property value is null. Error at object 'LearningWPF.ValidationRules.NotNullOrEmptyValidationRule' in markup file 'LearningWPF;component/addcustomerwindow.xaml' Line 35 Position 66."} 

Ecco la proprietà ValidationRules:

public static readonly DependencyProperty ValidationRulesProperty = 
      DependencyProperty.Register("ValidationRules", 
             typeof (Collection<ValidationRule>), typeof (RequiredTextBox), 
             new FrameworkPropertyMetadata(null)); 

     public Collection<ValidationRule> ValidationRules 
     { 
      get { return (Collection<ValidationRule>)GetValue(ValidationRulesProperty); } 
      set { SetValue(ValidationRulesProperty, value); } 
     } 
+0

Che tipo è ValidationRules? Sembra che tu stia cercando di aggiungere un oggetto a un tipo di raccolta, ma non hai istanziato la raccolta. –

+0

Ho aggiornato il post! – azamsharp

+0

È necessario creare un'istanza della raccolta prima di poter aggiungere elementi. Nel costruttore della tua classe RequiredTextBox aggiungi: ValidationRules = new Collection (); Ora sarai in grado di aggiungere elementi attraverso xmal. –

risposta

8

I vantaggi sono essenzialmente due:

primo luogo una proprietà di dipendenza viene creato solo quando viene utilizzato, questo significa che la classe TextBox può essere molto efficace, con un ingombro di memoria insufficiente in quanto ha un numero minimo di beni proprietà che occupano spazio sul mucchio. Questo è particolarmente importante in WPF dove tutti i controlli sono solo raccolte di tipi più e più specifici. Se ognuno di questi tipi interni ha dichiarato decine di proprietà per definire il comportamento e guardare, un controllo di alto livello come un pulsante finirebbe per avere le dimensioni di una classe con qualcosa nel campo da baseball di cento proprietà.

In secondo luogo, le proprietà di dipendenza possono essere legate a un oggetto diverso dal tipo per cui sono state create. Ciò consente il caso in cui un controllo può impostare una proprietà Grid.Column, che il controllo Grid può leggere e utilizzare per il layout. Ciò significa che non centinaia di classi di decoratori forniscono minuscole funzionalità richieste da altri controlli. Ciò significa che xmal è molto più intuitivo e leggibile.


A cura di affrontare l'esempio nella tua domanda rivisto:

Mentre la vostra proprietà convalida non guadagnerà molto beneficio dall'essere una proprietà di dipendenza (praticamente fuori le ragioni in tutte le risposte finora posso vedo davvero solo il mio commento sull'impronta di memoria che entra in gioco), e certamente non è vantaggioso come nel caso della proprietà Text di una casella di testo in cui si potrebbe voler legarla o cambiarla in base ad altre input, lo implementerei comunque come proprietà di dipendenza. Il mio ragionamento per questo è semplice; non guadagni molto, ma non ti costa nulla - non ho mai desiderato di aver usato una proprietà di base in un controllo personalizzato mentre quando ho iniziato a scriverli stavo aggiornando costantemente le mie proprietà di base alle dipendenze perché volevo alcune funzionalità extra.

In poche parole, mentre la proprietà di dipendenza è più complessa per definire che una proprietà normale lo utilizzerei ancora come standard de facto per i controlli WPF a meno che non ci fosse un buon motivo per fare diversamente. Più o meno allo stesso modo in cui una proprietà è lo standard per le classi, anche se un campo è più facile da implementare.

+0

Controlla il post aggiornato! – azamsharp

+0

Puoi elencare una coppia di proprietà di dipendenza che avrai nel controllo personalizzato in modo da avere un'idea migliore? – azamsharp

2

proprietà di dipendenza sono necessarie se si desidera utilizzare vincolante per popolare il valore di una proprietà. Se fosse solo una proprietà normale, non sarebbe possibile legare la proprietà Text a una proprietà dell'oggetto View Model, ad esempio.

5

I vantaggi principali direi sono:

  1. dati di prima classe di supporto vincolante.
  2. Semantica della proprietà Clean Attached
  3. Proprietà valori che "dipendono".

Questo ultimo punto è chiave

Prima proprietà di dipendenza, con un valore di avere un valore locale, un valore animatable, un valore di override, un valore styleable, un valore templatable richiederebbe la dichiarazione di molteplici Proprietà/Campi/Voci del dizionario, così come lo stato complesso + gestione della precedenza.

Le proprietà di dipendenza forniscono tutte queste funzionalità immediatamente, dichiarando solo UNA proprietà.

Detto questo, nel tuo caso, potresti non voler dichiarare ValidationRules come proprietà di dipendenza se non avrai bisogno di sfruttare queste funzionalità.

Se lo si desidera, si desidera avere una gestione diversa per le proprie raccolte (ad esempio, raccolte non vuote). In questo particolare esempio, vorrei utilizzare Reflector e vedere come .NET TextBox implementa le loro raccolte di convalida e vedere se è possibile riutilizzare o copiare il codice.

Non ha senso reinventare la ruota a meno che non siate certi di la vostra ruota sarà migliore. La mia esperienza personale è che le mie ruote reinventate tendono a perdere le cose;).

Come già sottolineato da Martin Harris, DependencyProperties può limitare l'ingombro della memoria lanciando i valori delle proprietà in un dizionario, tuttavia ciò può (e credo sia?) Eseguito da MSFT prima dell'avvento di DependencyProperties.

Martin menziona anche Proprietà allegate, ma anche quelle erano disponibili (almeno nella finestra di progettazione) prima dell'avvento di DependencyProperties. L'implementazione della proprietà associata utilizzando DependencyProperties è molto più pulita.

Problemi correlati