CODEWITHSUNDEEP
c#wpf
user310291
user310291

Reputation: 38228

What are drawbacks of creating a dependency property?

It is said here:

http://msdn.microsoft.com/en-us/library/ms753358.aspx

Sometimes, the typical technique of backing your property with a private field is adequate.

However, you should implement your property as a dependency property whenever you want your property to support one or more of the following WPF capabilities ...

If I look at all the capabilities they are very obvious needs so I can't really see when I should NOT create dependency property.

So if I systematically create a dependency property instead of just creating a private field what would be the drawbacks?

Upvotes: 1

Views: 592

Answers (3)

Euphoric
Euphoric

Reputation: 12849

DP should be used only when you are making / modifying new WPF control. Overhead is too much to be used as property on VM (and makes VM dependant on WPF). For normal usage you should implement INotifyPropertyChanged

Upvotes: 1

as-cii
as-cii

Reputation: 13039

It depends on what you need. For example if you need binding you MUST create a DependencyProperty. If you have to work with data that doesn't "communicate" with the graphical interface using a DependencyProperty is worthless and less performant because you don't need binding, animation, etc.

The purpose of dependency properties is to provide a way to compute the value of a property based on the value of other inputs. These other inputs might include system properties such as themes and user preference, just-in-time property determination mechanisms such as data binding and animations/storyboards, multiple-use templates such as resources and styles, or values known through parent-child relationships with other elements in the element tree. In addition, a dependency property can be implemented to provide self-contained validation, default values, callbacks that monitor changes to other properties, and a system that can coerce property values based on potentially runtime information. Derived classes can also change some specific characteristics of an existing property by overriding dependency property metadata, rather than overriding the actual implementation of existing properties or creating new properties.

Upvotes: 1

Eilistraee
Eilistraee

Reputation: 8290

there are in fact some drawbacks:

  • Creating a Dependency property is more verbose than a private field backed property.

  • When you use a Dependency property, your data is stored inside a Dictionary. It has some performance implications: The access lookup is done at runtime, the conversion too, and boxing/unboxing will occu because every dependency property values are stored as objects. Furthermore, all these capabilities come for a price (performance price) which you will pay with each access (read or write). Event will be raised (like PropertyChanged) validation will be performed according to your DP configuration...

  • Your class must inherit from DependencyObject

This is a price I am willing to pay when a need these capabilities. But they aren't needed in a lot of cases=> Use a DP when appropriate, a classic private field elsewhere.

There are case when you will regret that a property is not bindable: When it happens, replace the field with a DP implementation under the hood.

Upvotes: 3

Related Questions