Tracking dirtiness with DynamicProxy

When dealing with POCOs, a common scenario is to track changes. Look at this interface:

It is the interface of a simple view class containing the name and weight of a product. The Modified property is used to track whether the object has changed its value, so that we know if we should save the object after it has been edited.

A typical implementation might look like this:

It can be seen above that modified is set to true if a change is detected whenever a setter is called. This is pretty straightforward, yet it seems that an annoying pattern emerges when there is more than a few properties.

How can we then get rid of all the boilerplate code, all the noisy bits in between? Well, there is a way: by using Castle‘s DynamicProxy and a simple technique from aspect oriented programming called method interception. Read on to see an example.

With DynamicProxy your view class can look like this:

As you can see, it is much cleaner. And definitely more maintainable, as we have shaven off all the annoying bits. So how do we achieve the same behaviour without implementing the dirty tracking inside the view class?

Let’s specify our desired behaviour with a simple test:

As it can be seen, we want our view to start out as “not modified”. When we throw some values in it, it has suddenly become modified. Then we “forget” that it was modified, and set one of the values to the same value as before – still not modified. Then we actually change the name – now it should be modified. Then we do the same thing with a value type to assert the same behaviour applies when the values are boxed.

Note that the IView interface is used only so we can use the TestView method in both tests. Only the IDirtyCheckable interface must be implemented, so that we know that we can use the Modified property.

Let’s get on with the dirty tracking – we do it by creating a proxy class with DynamicProxy.

DynamicProxy is capable of doing what the name implies: dynamically building a proxy. It does some Reflection.Emit magic to dynamically subclass your view class. This subclass will contain overridden methods and properties for each virtual method or property in your base class, thus allowing something to be done each time a property or method is called. This something will be a call to the Intercept method of an implementation of the IInterceptor interface.

This is a phenomenon called method interception which is a key concept in aspect oriented programming.

Please note that it is important that methods and properties are virtual, otherwise the interception will not happen.

To actually do something, we need to supply the interceptor when creating the proxy. And we need some kind of help setting up the interception, because we do not want to do it manually every time we need an instance.

One possible solution is a DirtyChecker class, something like this:

Note how the type parameter <T> constrains the accepted types to be implementors of the IDirtyCheckable interface.

The static method GetNewDirtyCheckedObject<T> can now be used to create instances of our class. As you can see, the method is very simple, as it simply creates a ProxyGenerator, which in turn creates a proxy of our instance, applying an instance of the private class DirtyCheckableInterceptor to intercept method calls.

When a method call is intercepted, we can do some stuff and then decide whether we want to carry out the actual method call on the original object. This is done by calling Proceed on the supplied invocation argument.

In the example above, we detect if the desired method call is actually someone calling a set property on the object. If this is the case, we check the current value by calling the corresponding getter, comparing it to the desired new value. If they are not equal, we “dirtify” the object, and let the method call proceed.

Conclusion: By using DynamicProxy and method interception it is possible to track changes in a POCO object – completely transparent to the author of the POCOs, reducing the amount of boilerplate code.

3 thoughts on “Tracking dirtiness with DynamicProxy

  1. Wow… I only have one comment: What happened to “keep it simple”, and what about the increased computation requirements? And I don’t like the implementation of the AreEqual method either 🙂

    You are indeed more a computer scientist than a practical computer engineer 😛

  2. DRY. From now on, every time I add a new model class, I save myself the trouble of punching in if (someField != value) { (...).

    I don’t think the increased complexity will degrade performance, unless of cource you rely on being able to set the value of your object as fast as possible one million times a second all day long… which you most likely don’t! 🙂

    The AreEqual method is weird-looking, I’ll give you that. But it handles objects and boxed value types equally well, which the == operator did not.

    Du får en bajer for at være den første, der kommenterer i min nye blog 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.