Dynamically adding RaisePropertyChanged to MVVM Light ViewModels with IoC

in the past, i already wrote two articles about dynamically adding raisepropertychanged support to view models. today, i will explain how this can be accomplished with the ioc container: microsoft unity . unity has out of the box support for aop. using unity is much easier than my two previous do-it-yourselves ways. for real applications, i recommend using unity or similar frameworks!

like in my previous articles, i want to write view models using the following code pattern:

[raisepropertychanged]
public virtual string someproperty { get; set; }

instead of the standard pattern:

private string someproperty;

public string someproperty
{
    get
    {
        return someproperty;
    }
    set
    {
        someproperty = value;
        raisepropertychanged("someproperty");
    }
}

implementation

in order to get started, the first thing we have to do is install both unity and mvvm light. to do this, i recommend using nuget. in the official nuget repository, unity is split into two packages. for the aop support, both packages need to be added to the visual studio project.

now that we have all the required libraries, we can start coding. first, lets define our raisepropertychangedattribute class.

[attributeusage(attributetargets.property, allowmultiple = false)]
public class raisepropertychangedattribute : handlerattribute
{
    public override icallhandler createhandler(iunitycontainer container)
    {
        return new raisepropertychangedcallhandler();
    }
}

because we want unity to intercept calls, we must extend our attribute from handlerattribute . a custom handlerattribute must create and return a custom icallhandler instance. we will return an instance of our custom raisepropertychangedcallhandler that we will create next.

before writing our icallhander, we must first look at the msil code generated by the c# compiler in order to understand .net properties better. when a property is defined, 2 hidden methods are automatically created by the compiler; a get method and a set method. these methods have by default the name get_<property name> and set_<property name>.

with this knowledge in mind, the custom icallhandler implementation is straightforward. we ask unity to call the original set method and after its invocation we extract the name of property out of the name of the set method and we invoke the raisepropertychanged method of mvvm light using reflection.

class raisepropertychangedcallhandler : icallhandler
{
    public imethodreturn invoke(imethodinvocation input, getnexthandlerdelegate getnext)
    {
        imethodreturn methodreturn = getnext()(input, getnext);

        string propertyname = input.methodbase.name.substring(4);

        methodinfo raisepropertychangedmethod = input.target.gettype().getmethod("raisepropertychanged",
            bindingflags.instance | bindingflags.nonpublic, null, new type[] {typeof(string)}, null);
        raisepropertychangedmethod.invoke(input.target, new object[] { propertyname });

        return methodreturn;
    }

    public int order { get; set; }
}

configuring unity

all that now remains is configuring unity for our view model and activating virtual method aop support for it. in code, we can define this using the following code sample:

iunitycontainer container = new unitycontainer();
container.addnewextension<interception>();
container.registertype<sampleviewmodel>().
    configure<interception>().
    setinterceptorfor<sampleviewmodel>(new virtualmethodinterceptor());

if we now use unity for creating instances of our sample view model class, all the properties annotated with “raisepropertychanged” will atomically be “property change”-aware.

sampleviewmodel vm = container.resolve<sampleviewmodel>();