Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles
(untagged)

WPF: The calculated property dependency problem

0.00/5 (No votes)
30 Apr 2012 2  
In this article I'm going to speak about another nuance of the MVVM pattern; namely binding to calculated properties and updating the view when calculations change. I'm also crazy enough to propose a solution.

Introduction

Model-View-ViewModel (MVVM) is one of the new patterns (well maybe old now!) used to separate UI layers from model layers in applications. It's ubiquitously used in WPF and takes advantage of the extensive data binding support offered. While it's a wonderful separation pattern it certainly does have it drawbacks. For example, capturing non routed events on the view model. Developers have found numerous workarounds for issues like this including using attached properties and event-to-command wrappers just to name two of them.  In this article I'm going to speak about another nuance of the MVVM pattern; namely binding to calculated properties and updating the view when calculations change. I'm also crazy enough to propose a solution.

Background 

Step 1: Let's look into the abyss shall we!  

Below you will find a very simple ViewModel. Let's assume that a View is bound to it and the RaisePropertyChanged method is implemented correctly. Let's also assume that a WPF TextBlock on the View is bounded to the Name property.  

public class ViewModel: INotifyPropertyChanged
{
    private string name = String.Empty;
    private DateTime birthDate;
        
    public string Name
    {
        get
        {
           return name;
        }

        set
        {
            name = value;
            RaisePropertyChanged("Name");
        }
    }
}

If I now change the Name property in code, the TextBlock's Text will change since I called the RaisePropertyChanged method which raises the PropertyChanged event. Indeed this is the ideal case and is how view model property binding and notification works. 

Step 2: Let's climb down into the abyss

Let's modify our view model as follows:

public class ViewModel: INotifyPropertyChanged
{
    private string name = String.Empty;
    
    public string Name
    {
        get
        {
           return name;
        }

        set
        {
            name = value;
            RaisePropertyChanged("Name");
        }
    }

    public DateTime BirthDate
    {
        get
        {
           return birthDate;
        }

        set
        {
            birthDate= value;
            RaisePropertyChanged("BirthDate");
        }
    }


    public int Age
    {
        get
        {
           return DateTime.Today.Year-BirthDate.Year;
        }    
    }
}

Let's assume that in the second ViewModel a TextBlock on the View is bounded to Age, a calculated property. Careful readers will notice that when BirthDate is updated, the TextBlock on the view bound to Age will not update. This is because the view does not know that Age has changed (we never told it). Age also does not have a backing property! A solution to this issue is deceptively simple:

public class ViewModel: INotifyPropertyChanged
{
    private string name = String.Empty;
    
    public string Name
    {
        get
        {
           return name;
        }

        set
        {
            name = value;
            RaisePropertyChanged("Name");
        }
    }

    public DateTime BirthDate
    {
        get
        {
           return birthDate;
        }

        set
        {
            birthDate= value;
            RaisePropertyChanged("BirthDate");
            RaisePropertyChanged("Age");
        }
    }

    public int Age
    {
        get
        {
           return DateTime.Today.Year-BirthDate.Year;
        }    
    }

}

By calling RaisePropertyChanged("Age") in the setter of BirthDate the view will query Age and hence retrieve the correct value.  

While this solution works in this extremely simple case it will soon become a nightmare when we have numerous calculated properties with no setters. Calculated properties may even depend on each other! This will result in calling the RaisePropertyChanged method all over your code just to get the view and the view model to sync. Suddenly we are in the abyss and it's dark.

Step 3: Staring into the abyss (and not being afraid)

At this point the abyss is telling us to accept our fate (the solution above) and move on. But that's not who we are. We are warriors with sharp swords (c sharp, that is).

We need a solution to this issue which we can reuse across different view models. The last thing we need is to litter our code with property changed notification calls. What we need is a way to tell our view model that if a certain property changes then we should also raise a property changed event of any property that depends on it. We need a kind of parent-child property thing-y.

Step 4: Fighting the abyss (does that even make sense?)

Let's modify our view model as follows: 

public class ViewModel: INotifyPropertyChanged
{
    private string name = String.Empty;
    
    public string Name
    {
        get
        {
           return name;
        }

        set
        {
            name = value;
            RaisePropertyChanged("Name");
        }
    }

    [DependentProperties("Age")]
    public DateTime BirthDate
    {
        get
        {
           return birthDate;
        }

        set
        {
            birthDate= value;
            RaisePropertyChanged("BirthDate");
            RaisePropertyChanged("Age");
        }
    }

    public int Age
    {
        get
        {
           return DateTime.Today.Year-BirthDate.Year;
        }    
    }
}

Notice that I have annotated the Birthdate property with an attribute called DependentProperties. I have also removed the RaisePropertyChanged method call from the setter of BirthDate.

Using the mechanism we can say that whenever BirthDate is updated the property changed event of Age should also be raised. The view will be notified that Age has 'changed' and query it. The view and the view model will be in sync.

Benefits  

  • A higher level of abstraction when dealing with calculated properties
  • Less code to write
  • Less code to maintain 
  • No 'tracking down' of which properties depend on each other.
  • A solution to the calculated property dependency problem in WPF.

Step 5: Punching the abyss in the gut (aka the implementation)!

Let's describe the DependentProperties attribute class.

public class DependentPropertiesAttribute: Attribute
{
    private readonly string[] properties;

    public DependentPropertiesAttribute(params string[] dp)
    {
        properties = dp;
    }

    public string[] Properties
    {
        get 
        {
            return properties;
        }
    }
}

It derives from Sytem.Attribute and has a simple Properties field. This field holds all the dependent properties (properties that need to be re-queried when the annotated property value changes).

Now let's look at who consumes the DependentProperties attribute.

The magic is in the RaiseProperty procedure:

public class ViewModelBase: INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;

    protected void RaiseProperty(string propertyName, List<string> calledProperties = null)
    {
        RaisePropertyChanged(propertyName);

        if (calledProperties == null)
        {
            calledProperties = new List<string>();
        }
     
        calledProperties.Add(propertyName);
      
        PropertyInfo pInfo =  GetType().GetProperty(propertyName);

       if (pInfo != null)
       {
           foreach (DependentPropertiesAttribute ca in 
             pInfo.GetCustomAttributes(false).OfType<dependentpropertiesattribute>())
           {
               if (ca.Properties != null)
               {
                   foreach (string prop in ca.Properties)
                   {
                       if (prop != propertyName && !calledProperties.Contains(prop))
                       {
                           RaiseProperty(prop, calledProperties);
                       }
                   }
               }
           }
       }
    }

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

Step 5: Making the abyss beg for mercy

The algorithm, although it looks complex, it quite simple:

  1. Call RaiseProperty method for a property.
  2. Get all the dependent properties for that property.
  3. Call RaiseProperty on them as well.
  4. Avoid stack overflow exceptions from properties who depend on each other either directly or indirectly by keeping a list of called properties.

Step 6: Climbing out from the abyss

At the this you survived the abyss. You are much stronger than it!

Points of Interest 

Although I feel that this solution is elegant it still relies on reflection to get the dependent properties. Also a list of called properties must be maintained per top level RaiseProperty call. This solution can be used when performance is not an issue. I believe the small performance hit due to reflection far outweighs the complexity of dealing with dependant and calculated properties. You have the option of also using a hybrid approach. For example, for calculated and dependent properties call the RaiseProperty method. For properties that do not need this just call the general RaisePropertyChanged event.

The solution can also be optimized to cache the dependent properties whereby avoiding the reflection call.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here