Siverlight 4 - Using DependencyObjects or INotifyPropertyChanged as data objects / ViewModel

Making conviencing decision on representing data objects as whether to derive from DependencyObject or implement from INotifyPropertyChanged can sometimes become a daunting task. When implementing MVVM pattern this question arises while representing the ViewModel.

DependencyObject provides support for handling dependency properties. It is the dependency property which is capable of handling the data binding even through XAML (markup) extensions. There is no need for the manually notify the change in the property value, since the dependency property system automatically notifies the changes in the property.

Snippet 1 (Dependency property)

public static readonly DependencyProperty ValueProperty = DependencyProperty.Register("Value", typeof(string), typeof(ParameterMapControl), null);

public string Value
{
    get
    {
        return (String)GetValue(ValueProperty);
    }
    set
    {
        SetValue(ValueProperty, value);
    }
}

Snippet 2 (INotifyPropertyChanged)

public class SampleViewModel : INotifyPropertyChanged
{
    private string reportName;

    public string ReportName
    {
        get { return reportName; }
        set
        {
            reportName = value;
            NotifyPropertyChanged("ReportName");
        }
    }


    #region INotifyPropertyChanged Members

    public event PropertyChangedEventHandler PropertyChanged;

    protected void NotifyPropertyChanged(string propertyName)
    {
        if (PropertyChanged != null)
        {
            PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
        }
    }

    #endregion
}

Ok now think of in a different perspective, if the ViewModel is derived from the DependencyObject, exposed a dependency property and it is bind to the control in UI, any change in the property will notify the control. As an alternate we can implement the ViewModel from INotifyPropertyChanged which is usually represented as Plain Old CLR Objects (POCO) and manually provide the mechanism to notify the property changed.

The evaluation of property value, usage of resources (like memory) and the handling of binding sequence are well optimised to handle by the DependencyObject. Hence using DependencyObject to build data objects is not wrong. But we should also consider other factors.

Case 1
When we use INotifyPropertyChanged (POCO model) for data objects, in general the change notification code will be placed in the setter of the specific property. Also, the property change notification can be raised whenever required. This is especially helpful for read-only properties. While developing view model, several times we might be in a situation to specify a read-only property. For example, we can specify a read-only property which holds the functionality that represents a collection in sorted order and each and every time the original collection got changed, will trigger the change notification for the related read-only property.  But dealing this situation with DependencyObject is not pretty straightforward.

Case 2
Serialization of ViewModel will be your choice lot of time when you want to persist the state of the ViewModel for cases like reverting the object to a particular/previous state. Serialization mechanisms can be achieved over POCO easily where with DependencyObject,  we can't to do so.

Case 3
Passing as parameter to other services also favors POCO.

Case 4
Code readability, maintainability and flexibility are some of the main tenet of coding. DependencyObject lacks in these items when the ViewMode / data item goes a bit complex. Hence POCO is preferable here.

Summary
From the above, we can infer that implementing INotifyPropertyChanged for data items is handy in most of the cases. Dependency properties support great if it is the target of binding, animation, styles, template binding, etc, which will be very much helpful for us when we create custom controls.