Dependency Properties

In tecnologie come Windows Workflow Foundation o Windows Presentation Foundation è facile incontrare le Dependency Properties.
In sostanza sono delle proprietà che a differenza delle "comuni" property, non hanno il valore settato tramite un membro privato (come da esempio):

   1: private int _myProperty = 0;

   2: public int MyProperty

   3: {

   4:   get

   5:   {

   6:     return _myProperty;

   7:   }

   8:   set

   9:   {

  10:     _myProperty = value;

  11:   }

  12: }

ma all'interno di un repository centralizzato che funziona come un Dictionary che contiene i valori correnti delle singole proprietà. Questo repository è un oggetto che deve ereditare dalla classe base DependencyObject dalla quale tutti gli acvitiy derivano:

   1: public int TestProperty

   2: {

   3:   get { return (int)GetValue(TestPropertyProperty); }

   4:   set { SetValue(TestPropertyProperty, value); }

   5: }

   6:  

   7: public static readonly DependencyProperty TestPropertyProperty =

   8:     DependencyProperty.Register("TestProperty", typeof(int), typeof(Workflow1));

Per dichiarare la proprietà TestProperty è necessario l'uso del metodo statico Register della classe DependencyProperty a cui passare il nome, il tipo della proprietà e il tipo della classe padre.
Come valore di ritorno otteniamo l'identificatore per accedere alla proprietà e non il suo valore.
A cosa servono?
E' possibile esporre le varie proprietà dei nostri custom activity ad altre attività presenti sul flusso creando così un legame fra le varie proprietà ( activity binding):

Come si può notare dall'immagine è possibile, tramite il designer, collegare le varie dependency properties esposte dalla custom activity selezionata.
Personalmente credo che le dependency properties non devono essere considerate come un "requisito" ma piuttosto qualcosa di estremamente utile.