INotifyPropertyChanged vs. DependencyProperty in ViewModel

Question

When implementing the ViewModel in a Model-View-ViewModel architecture WPF application there seem to be two major choices how to make it databindable. I have seen implementations that use DependencyProperty for properties the View is going to bind against and I have seen the ViewModel implementing INotifyPropertyChanged instead.

My question is when should I prefer one over the other? Are there any performance differences? Is it really a good idea to give the ViewModel dependencies to WPF? What else do I need to consider when make the design decision?

Solution 1

Kent wrote an interesting blog about this topic: View Models: POCOs versus DependencyObjects.

Short summary:

1. DependencyObjects are not marked as serializable
2. The DependencyObject class overrides and seals the Equals() and GetHashCode() methods
3. A DependencyObject has thread affinity – it can only be accessed on the thread on which it was created

I prefer the POCO approach. A base class for PresentationModel (aka ViewModel) which implements INotifyPropertyChanged interface can be found here: http://compositeextensions.codeplex.com

Solution 2

According to the WPF performance guide, DependencyObjects definitely perform better than POCOs that implement INotifyPropertyChanged:

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

Solution 3

The choice is totally based on your business logic and UI abstraction level. If you dont want a good separation then DP will work for you.

DependencyProperties will be applicable mainly at the VisualElements level so it won't be good idea if we create lot of DPs for each of our business requirements. Also there is a greater cost for DP than a INotifyPropertyChanged. When you design a WPF/Silverlight try to design UI and ViewModel totally separate so that at any point of time we can change the Layout and UI controls (Based on theme and Styles)

Refer this post also - https://stackoverflow.com/questions/275098/what-applications-could-i-study-to-understand-datamodel-view-viewmodel . The link has a lot of reference to Model-View-ViewModel pattern, which is very relevant to this discussion.

Solution 4

From an expressiveness standpoint, I thoroughly enjoy using dependency properties and cringe at the thought of INotifyPropertyChanged. Apart from the string property names and possible memory leaks due to event subscription, INotifyPropertyChanged is a much more explicit mechanism.

Dependency properties imply "when this, do that" using easily-understood static metadata. It is a declarative approach that gets my vote for elegance.

Solution 5

Dependency properties are intended to supports binding (as a target) on UI elements not as a source to data binding, this is where INotifyProperty comes in. From a pure point of view you shouldn't use DP on a ViewModels.

"In order to be the source of a binding, a property does not need to be a dependency property; you can use any CLR property as a binding source. However, in order to be the target of a binding, the property must be a dependency property. For a one-way or two-way binding to be effective, the source property must support change notifications that propagate to the binding system and thus the target. For custom CLR binding sources, this means that the property must support INotifyPropertyChanged. Collections should support INotifyCollectionChanged."

All dependency objects cannot be serialised (This could hamper the use of ViewModels and DTO (POCO)'s.

There are differences between DP within Silverlight compared to WPF.

http://msdn.microsoft.com/en-us/library/cc221408(v=VS.95).aspx

http://msdn.microsoft.com/en-us/library/cc903933(VS.95).aspx

View more solutions

Comments

[Joe White]

You can get change notifications from DependencyProperties as well. See PropertyMetadata.PropertyChangedCallback. Example at: msdn.microsoft.com/en-us/library/ms745795.aspx

[naveen jayanna]

The post by jbe answers the differences more accurately. Just because a VM (or Presenter) inherits from DependencyObject doesn't mean that it can't be styled or isn't logically separate from the View, it just means that the storage for the property values is different than explicitly declared fields in the POCO style. That being said, serialization, logical equality, and thread affinity are real issues which DepedencyObject-based VMs have to deal with.

[codekaizen]

DependencyObject also takes a dependency on the WPF libraries, whereas POCO does not, allowing your view models to drive some other UI stack where WPF isn't available (Compact Framework, Mono).

[Andrei Rînea]

It's clear then, that the Dependecy Properties are solely built for the UI and not for the business layer.

[oillio]

An INotifyPropertyChanged can be used in either case. You can bind TwoWay to it. A DependencyProperty is required for technical reasons only for some actions performed on a View object (setting some properties when instantiating a View object in XAML, for instance). A DependencyProperty is never required for a ViewModel.

[Jonathan ANTOINE]

I must agree on that one ;-) : blog.lexique-du-net.com/index.php?post/2010/02/24/…

[aL3891]

Also, you can call SetValue from anywhere as well, not just from inside the property

[Gusdor]

Dependancy Properties also require a DependencyObject parent. Your ViewModel really shouldn't inherit from DependencyObject.

[Gusdor]

By answering, you seem to be making the assumption that bitbonk considers XAML and WPF to be the same. ViewModels should have as few WPF dependancies as possible, not to increase logical separation, but to decrease code complexity and avoid all the issues associated with simply writing logic in a user control's code-behind. You will inevitably implement WPF concepts like ICommand and present behaviour that only WPF / Silverlight will be able to wrap easily - your only presentation threading concerns in a view model should be CollectionViews and ObservableCollection.

[Tilak]

Without INotifyPropertyChanged, PropertyDescriptor are used, which causes memory leaks

[Michael L Perry]

The Update Controls library that I present in that blog post uses weak references, not property descriptors. It does not leak memory.

[Der_Meister]

Michael, your library generates a lot of code. I don't see benefits. I can achieve the same by generating model wrapper with generated PropertyChanged event calls.

[doubleYou]

If you select .NET Framework version 4, then the link still works. It's just not available for "current version".

[Newtopian]

The string part now has a solution with the nameof operator.

[Bryan Watts]

@Newtopian: True. There are also some interesting things possible with [CallerMemberName].

[tpartee]

I've been using serialized Dependency Objects since 2009 without issue, so not sure what you're talking about when you say "All dependency objects cannot be serialized" - yes they can. In fact there are many options: codeproject.com/Articles/61440/… emphess.net/2008/11/25/dependencyproperty-serialization And one of my personal favorites: just provide backing stores for all of your DPs and make those serializable (no good simple examples were readily available in 2 minutes of searching on Google, but I assure you this works).

[tpartee]

This is misleading and untrue - there are multiple ways to hook into change events on a DP, even when it's changed 'internally'. One of them was pointed out above by Joe White

[tpartee]

Thanks for pointing this out, there's a lot of scandalous misinformation out there of devs making salacious claims that INotifyPropertyChanged is faster or incurs less overhead than DPs and it's simply unfounded. DPs are fast, elegant and powerful ways to structurally define the virtual (data) tree.

[tpartee]

"Also there is a greater cost for DP than a INotifyPropertyChanged" - where is your source of proof on this? A lot of devs make this claim without any evidence to support it. According to MSDN it's not true. "try to design UI and ViewModel totally separate so that at any point of time we can change the Layout and UI controls" - again, this has absolutely nothing to do with POCO + PropChange versus DO/DP. If anything, the Reflection and Path registry in DO/DP improves your ability to work on the visual side.

[tpartee]

Not to mention the wealth of Property Registration (Reflection) benefits in WPF and CLR when using a DO/DP model versus a POCO.

[HASSAN MD TAREQ]

Code sample, please

[ed22]

There is a hidden evil to the DependencyObjects. They need to be created on the same thread as the controls that bind to them. That means GUI thread. That means you need to Dispatch the creation to that thread. You can't have those things loaded and created on some background thread from DB for example. Unless you dispatch the creation. Insane.