When to use Dependency Properties

问题

I sometimes think I maybe using Dependency Properties unnecessarily. When do I need to use it? When I have a property that dependes on other properties? Say I have a Color property that I want it to be dependent on properties Hue, Saturation, Luminosity do I use a dependency property? Or what do I use? I controls thats bound to Color to update when properties Hue, Saturation, Luminosity are changed.

for now what I did was

public byte Hue {
    get { return _hue; }
    set
    {
        if (_hue == value)
            return;
        _hue = value;
        NotifyPropertyChanged("Hue");
        NotifyPropertyChanged("Color"); // to update controls bound to color
    }
}

But I think this is not the right way of doing things? If I have more properties that affect color, I will have 1 extra line in all those properties?

回答1:

You should only use a DependencyProperty when you want to be able to bind its value to something through XAML, e.g.

<local:MyObject MyDependencyProperty="{Binding ...}" />

Update: as mentioned by Ian below, dependency properties are also required if you want to be able to animate your property or set it through a style

If you do not need to work in this way then it is unnecessary. e.g. If you just want to be able to set the value to a constant through XAML (as below) this will work without using a DependencyProperty

<local:MyObject MyRegularProperty="Some Value" />

Similarly, if you want to bind to the value of a property on (for example) your view model:

<TextBlock Text="{Binding MyViewModelProperty}" />

then you do not need to use a DependencyProperty. Provided that you implement INotifyPropertyChanged then the Text will still be updated when the property changes.

Edit: on re-reading your question, I am not sure whether or not your situation will be affected by whether or not you use a DependencyProperty - if I'm reading it correctly, all you want to do is cause a number of properties to be updated on the UI when any one of those properties changes, right?

I don't think there is anything wrong with how you are implementing things at the moment (i.e. raising a lot of PropertyChanged events in each setter), but if you aren't keen on in then you could try having a single property that exposes relevant child properties to bind to that are all calculated:

class ColorWrapper
{
    public Color Color  { get; set; }
    public byte Hue
    {
        get { return this.Color.Hue; } //or however this is calculated
}

Then have a Color property on your ViewModel that raises the PropertyChanged event and bind to that through the View:

<TextBlock Text="{Binding Color.Hue}" />

As I said, I wouldn't say that this is particularly an improvement on what you have already though.

回答2:

The general rules are:

For XAML controls, use dependency properties;
For data (which you bind to in the interface), use INotifyPropertyChanged.

There are exceptions, but they are rare.

回答3:

Another use of dependency properties is with navigation journal. Custom dependency properties on a Page with Juornal flag in the meta-data are included in the state that WPF saves for the page.

回答4:

Remember that Dependency Properties, although they allow Binding either as a source or a target, are also Thread-Sensitive, and when serializing you will have to use a surrogate, serialization as DependencyObject isn't serializable.

Oh, and Equals and GetHashCode are sealed :(

来源：https://stackoverflow.com/questions/4104154/when-to-use-dependency-properties

标签

wpf

dependency-properties