DynamicProxy2: CreateClassProxyWithTarget + IInterceptor

Question

If I've missed this in another question I apologize; I looked for a good while before deciding I had a unique question... I want to use DynamicProxy2 to provide interception for a WPF application's model classes. This is so that I do not have to fully implement INotifyPropertyChanged everywhere. For instance, the below class should fully participate in two-way data binding once proxied and intercepted:

public class ModelExample : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;

    public int Id{ get; set; }
    public string Uri{ get; set; }
    public string Name{ get; set; }
}

I have found that I can create a new instance of the model class and intercept calls to it by calling the CreateClassProxy method:

new ProxyGenerator().CreateClassProxy<T>(interceptors);

Unfortunately, this forces me to allow the ProxyGenerator class to create my model instances, and I'm getting those back from my middle tier, i.e. they already exist. I need to wrap existing objects, so I think I need to call CreateClassProxyWithTarget instead:

new ProxyGenerator().CreateClassProxyWithTarget(instance, interceptors);

However, when I do that my interceptor stops functioning. I'm pretty sure it's not the interceptor's fault... it's a very simple object. Here's its interface:

public interface IFluentInterceptor : IInterceptor
{
    IFluentInterceptor Before(Action<IInvocation> before);
    IFluentInterceptor After(Action<IInvocation> after);
    IFluentInterceptor Finally(Action<IInvocation> @finally);
    IFluentInterceptor RunCondition(Func<IInvocation, bool> runCondition);
    IFluentInterceptor OnError(Func<IInvocation, Exception, bool> onError);
}

The FluentInterceptor type implements this. The Before, After, etc. methods are too simple to show; they all add to action queues that are meant to be used during method invocation, then each method returns this, allowing for method chaining.

The below code doesn't work, but I can't figure out why:

new ProxyGenerator().CreateClassProxyWithTarget(instance, new FluentInterceptor()
    .After(invocation =>
    {
        if (!invocation.Method.Name.StartsWith("set_")) return;
        string propertyName = invocation.Method.Name.Substring(4);
        FieldInfo info = invocation.TargetType.GetFields(BindingFlags.Instance | BindingFlags.NonPublic)
            .Where(f => f.FieldType.Equals(typeof (PropertyChangedEventHandler)))
            .FirstOrDefault();
        if (info == null) return;
        var handler = info.GetValue(invocation.InvocationTarget) as PropertyChangedEventHandler;
        if (handler != null) handler.Invoke(invocation.TargetType, new PropertyChangedEventArgs(propertyName));
    }));

If I try that with CreateClassProxy, it works like a charm. Does anybody see what I'm doing wrong?

Thanks!

Answer 1

Honestly, I think this is a non-issue. If I ever need a container to generate the INotifyPropertyChanged implementation for me, it'll probably be in fringe cases where I'm plugging in model objects that get built by the container anyway because they have depedencies, etc. In those cases CreateClassProxy<T>(interceptors) is fine. In all other cases I have been using MVVM ViewModels where the exact logic surrounding change notification is decided on a case-by-case basis, with the user experience being the focus. Model classes usually get flattened or transformed in some way, so the whole point is moot. I asked this question at a time when I didn't understand how to properly leverage MVVM in my app, and I thought I was going to be responsible for more moving parts. It's actually been a lot easier than anticipated, once I started configuring my ViewModels properly.