Property Change Wrapper

Apr 29, 2011 at 1:20 AM

What are your thoughts on the property change wrapper I describe here:

Being integrated into Jounce? It would just be to help take flat, non INotifyPropertyChange types and easily convert them, and likely would not be a base part of the view model hierarchy (unless you think it should be - I think view models would just expose types of this).

Thoughts? Interest? Or is mapping trivial and not something the framework needs to address? I'm thinking specifically for longer lists of items that you want to capture property change on ...


Apr 29, 2011 at 3:47 PM
Edited Apr 29, 2011 at 3:58 PM

Hi Jeremy,

I do like the idea of providing a generic INPC-proxy for POCO-classes as an integral part of Jounce. As you correctly state in your referenced blog post, all of the approaches suggested so far suffer from one shortcoming or the other - such as added dependencies on 3rd party assemblies for IL weaving or AOP - if they even work reliably at all.

When it comes to a practically feasible mechanism that matches the excellent quality of the Jounce framework, however, there are a couple of points I'd like to raise on the implementation you suggest in your other post:

  1. An INPC proxy must be able to work for non-simple property types (e.g. collections and complex types). None of the Models/ViewModels that I find in my projects are made up from only simple property types, and it's just not worth bothering with a mechanism that doesn't support real-life data structures.
  2. Don't create additional buffering fields in the dynamically created proxy class and don't initiate value write-back in an INPC event handler. Instead, route Getter/Setter methods through to the underlying instance Getter/Setter methods. Avoiding a duplication of the entire property data set is well worth the disadvantage of an additional method call in the Getter, especially if the Getter can be a DynamicMethod.

As a corollary to 1. an INPC proxy should be able to recursively initiate the creation of proxies for the types of complex properties. That is, creating an INPC proxy for

public class Person {

   public List<Address> Addresses { get { ... } }


should lead to the transparent creation of an INPC proxy type for class Address.

Now this is where things tend to get messy if your underlying Model classes define cyclic references. We just ran into precisely this type of a situation in one of our projects and we're having a hard time avoiding stack overflows in automatically generated ViewModel classes.

So by all means go ahead and integrate generic INPC support into Jounce - it will be greatly appreciated. Just please don't restrict it to simple property types.