2013-03-14 9 views
5

Podążałem za tutorialem na temat obiektu zależności: tutaj: http://tech.pro/tutorial/745/wpf-tutorial-introduction-to-dependency-propertiesJak jest używana klasa dziedzicząca DependencyObject?

Jednak nadal jestem nieco zdezorientowany. I stworzył następujące klasy, która jest wyłącznie dla własnych celów uczenia się i nie ma realnego wykorzystania:

namespace DPTest 
{ 
    class Audio : DependencyObject 
    { 
     public static readonly DependencyProperty fileTypeProperty = DependencyProperty.Register("fileType", typeof(String), typeof(Audio), 
     new PropertyMetadata("No File Type", fileTypeChangedCallback, fileTypeCoerceCallback), fileTypeValidationCallback); 

     public String fileType 
     { 
      get 
      { 
       return (String)GetValue(fileTypeProperty); 
      } 
      set 
      { 
       SetValue(fileTypeProperty, value); 
      } 
     } 

     private static void fileTypeChangedCallback(DependencyObject obj, DependencyPropertyChangedEventArgs e) 
     { 
      Console.WriteLine(e.OldValue + " - " + e.NewValue); 
     } 

     private static object fileTypeCoerceCallback(DependencyObject obj, object o) 
     { 
      String s = o as String; 
      if (s.Length > 0) 
      { 
       s = s.Substring(0, 8); 
      } 

      return s; 
     } 

     private static bool fileTypeValidationCallback(object value) 
     { 
      return value != null; 
     } 
    } 
} 

kilka pytań:

  1. Dlaczego jest właściwość statyczna? Nie w pełni rozumiem, czy ma to na celu zapisanie wartości na poziomie obiektu.
  2. Co robi wywołanie zwrotne Coerce i dlaczego jest uwzględnione?
  3. Jaki jest cel mojej klasy i gdzie powinienem jej użyć?

Odpowiedz

8

Długie i krótkie na to jest prawdopodobnie nie będzie musiał DependencyObject na jeśli pójdziesz Model-View-ViewModel, ale aby odpowiedzieć na konkretne pytania:

  1. DependencyProperty definicji są statyczne, ponieważ wszystkie instancje DependencyObject udostępnia definicję. Są jak fancier per-object property Dictionary. Pozwala to również na płynne działanie różnych funkcji ramowych, takich jak Binding or rendering updates.

  2. DependencyProperty Coercion occurs kiedy trzeba połączyć ze sobą zmiany właściwości. Na przykład, jeśli masz kontrolkę suwaka, która ma wartość, która powinna istnieć między wartością minimalną a maksymalną, użyj wywołania zwrotnego CoerceValue, aby upewnić się, że pozostaje w odpowiednim zakresie.

  3. DependencyObjects wypadły z łaski w kodzie użytkownika, a zamiast tego są w znacznym stopniu wyparte przez wzorzec Model-View-ViewModel w rozwoju WPF. Gdzie nadal znajdziesz DependencyObjects są w rozwoju kontroli niestandardowej. DependencyProperties są powszechne w kodzie użytkownika, zwykle w postaci Attached Properties.

+0

Więc nie ma naprawdę pożytku z używania DependencyProperties w ogólnym projektowaniu komputerów i aplikacji mobilnych przy użyciu WPF? Kiedy najprawdopodobniej będę ich potrzebować? –

+0

To dość szerokie pytanie, które opisałem w mojej odpowiedzi na # 3. – user7116

3

Właściwość dependency sama w sobie jest statyczna, ponieważ przypisujesz właściwość do typu obiektu. Identyfikuje właściwość jako całość i nie tylko przechwytuje wartość, jak właściwości CLR.

Jak widać w (nie statycznej) właściwości CLR, funkcje przechowywania są obsługiwane tylko przez SetValue i GetValue. Możesz wyobrazić sobie wartości właściwości zależności jako duży słownik, w którym umieścisz tylko dowolną treść. Kluczem do słownika jest właściwość zależności.

Callback coerce jest używany do wymuszenia wartości w pewnym formacie. W twoim przypadku upewni się, że ciąg ma tylko 8 znaków. Najczęściej nie potrzebujesz takiego oddzwaniania. Nie trzeba nawet często zmieniać wywołania zwrotnego właściwości. Najczęstszym przypadkiem są tylko właściwości bindable i wystarczy zdefiniować właściwość zależności za pomocą standardowych metadanych.

Celem twojej lekcji jest służyć jako przykład, jak sądzę. Jeśli nie masz konkretnego przypadku użycia, nie radziłbym nawet patrzeć na obiekty zależności. W rzeczywistości bardzo rzadko podtyp DependencyObject sam w sobie. Zwykle masz element lub składnik szkieletu, który dziedziczysz i dodajesz do niego niestandardowe zachowanie. A następnie, gdy potrzebna jest właściwość bindable dla XAML itp., Wymagana jest właściwość zależności.

Powiązane problemy