Up, Up, and Away!

Get rid of those Magic Strings! Creating ViewModel properties using Lambda Expresssions with MVVM Light Toolkit’s ObservableObject class

If you want a target property to update, based on its source’s current property value, somehow you need to notify the binding system that the source’s property has been set or changed. If the source and target properties are dependency properties this binding happens automatically via Binding.ElementName Property. For instance, when binding an element’s property, such as the SelectedItem.Content property of a ComboBox control, to a Canvas control’s Background property.

Example taken from

However, in cases where the binding source is a data object of some sorts (ViewModel or Model object), we need to manually notify the binding system that a change has happened to the binding source’s values. This is accomplished using the INotfiyPropertyChanged interface.

A typical MVVM ViewModel would be implemented as such:

When used this way, we have to worry about Magic Strings in our code. The Magic String here would be the property name “Id” indicated on line 10. So whats the fuss with using a magic string then? Well, as Rob Connery’s blog mentioned:

 There’s no compile-time checking on a string. Duh…

On top of this, explained further on Rob Connery’s blog as stated by Jimmy Bogard in regards to Magic Strings…

  1. They don’t react well to refactoring
  2. It’s rampant, pervasive duplication
  3. They’re easily broken with mispelling
  4. If I change the name of the parameter in the Edit method, all code expecting the parameter name to be something specific will break. This wouldn’t be so bad if I had to change just one location, but I need to fix all places that use that parameter (likely with a Replace All command)

Continuing with INotifyPropertyChanged, we can implement this using Laurent Bugnion’s MVVM Light Toolkit’s ObservableObject base class. When a property is changed at the source, an event is raised with the name of the property as one of arguments. The binding system notices and catches this raised event it then requeries the value when it receives it. RaisePropertyChanged is inherited by the use of the ObservableObject base class. In that, RaisePropertyChanged method notifies any listeners, the binding system and anything that is subscribed to the event, that a property value has changed. Underneath it all, RaisePropertyChanged calls the INotifyPropertyChanged.PropertyChanged event and its associated PropertyChangedEventArgs class. In retrospect, it shields you from having to call INotifyPropertyChanged.PropertyChanged directly as shown in the previous snippet of code. RaisePropertyChanged is called from the setter of the property, which then guarantees that it will fire every time a value is changed on the property. The way that the binding system works, is that the property change notifications always specify the property name as a string.

How do we go about re-mediating the issue of using Magic Strings in our code? The solution to this would be the use of lambda expressions. The MVVM Light Toolkit has built-in support for compile-time checking in the change notification using lambda expressions. This is something you would not get using regular string properties. In the following example we will do just that. We will remove the use of string properties and replace that using lambda expressions.

The MVVM Light Toolkit’s ObservableObject base class includes variations of the method name Set. The <type>  of the Set method call is optional. It takes in a lambda expression that points to the property itself, a referencing to the backing property, and a new value. We now have compile time verification, and that we correctly set the property names in use, by removing the use of strings.

With this approach, we can now eliminate binding issues of property names due to mistype strings being passed to the RaisePropertyChanged method call. The Set method checks to see if the value being passed is different from the original value, if so, it uses the lambda expression to determine the property name, by reflection (it must reflect on the model to convert the name to a string), and then raises the property changed notification once the backing field is set. This allows your code, in regards to your ViewModels properties, to be solid.


Brown, Pete. “Windows Store App Development: C# and XAML“. Shelter, Island, NY: Manning, 2013. Print.

Connery, Rob. “The Wisdom and Magic of Strings” 10 March 2011. Web. 23 July 2013.

Recommended Reading:

Windows Phone 8 in Action (Paperback)

List Price: $44.99 USD
New From: $3.19 USD In Stock
Used from: $3.56 USD In Stock

Windows Store App Development: C# and XAML (Paperback)

List Price: $49.99 USD
New From: $25.58 USD In Stock
Used from: $4.44 USD In Stock

Silverlight 5 in Action (Paperback)

List Price: $59.99 USD
New From: $10.99 USD In Stock
Used from: $0.98 USD In Stock

Hi, my name is David. I am a .Net, Windows Phone, Windows 8 developer. I created @gogetter for Windows Phone

about newsletter

Support my gambling addiction.

Donate via Paypal
Filed under: Blog, MVVM