It’s been a while since I’ve posted anything. Sorry about that. This has mainly been due to a busy social and work schedule which has not given me the time I’ve needed to create the content that’s been floating around my desk as post it notes. In this post I would like to revisit dynamic typing support in .NET 4.0 and apply it to a real world scenario.
Proxying and Interception with Dynamics
If you’re like me then I imagine you have been playing with
.NET 4.0 for quite a while now. There is a wealth of new language features to play with in this release and I’m excited about the RTM come march. One of the features I have discussed previously is the support for dynamic typing.
Dynamics brings with it some new approaches to problems that
static languages have often found difficult to solve. In this post we will be looking at the topic of dynamic proxying, interception and
AOP.
The common goal of these techniques is to allow a programmer to be able to inject code transparently before and after a method has been invoked. This is illustrated below in the diagram below.
If you have not come across this concept before you may ask what is the point of intercepting a method before and after execution. A layer of
indirection is particularly useful when trying to inject code between a client and our objects. The reason we do this as it allows us to implement secondary support functions such as logging, transaction management, code contracts and other utility code outside the body of our method. What we find when we implement an proxy pattern is that once we have removed this secondary code the readability of our code improves tremendously and we have also increased our
separation of concerns.
Now you can see the benefits of this approach, let’s turn our attention to how we go about implementing this in our code. Luckily for us there has been a lot of smart people working hard to help make this process easier. If you do a search for proxy pattern’s or aspect orientated programming you will find a heap of information. When it comes to AOP there are a number of frameworks which have already been developed. These are listed below.
Aspect#
Encase AOP
Spring.NET
Aspect.NET
AspectDNG
Dynamic Proxy
Compose*
Loom.NET
PostSharp
Each of these frameworks make use of a number techniques to the injection of code both before and after execution of a method. These generally fall into 4 categories.
MSIL injection – Here we inject MSIL code into the body of the method being executed. (Post sharp)
Runtime dynamic injection – Using techniques such as reflection we invoke methods dynamically.
Type builder injection – Related to runtime injection, we create a type based on the type we wish to proxy and then marshal requests through this type. (
Dynamic Proxy)
Container injection – Requests pass through a container which invokes code before and after our method being executed.
WPF Bindings with dynamic objects
So now that C# 4.0 brings with it support for dynamic objects I thought I would take a look at how I can go about implementing a simple interception pattern for static objects. I am currently working on a project which makes extensive use of WPF. We follow and
MVP pattern and our views are bound directly to our presenters in order to reduce the amount of code in our views. If you have worked with WPF you will probably know some of the great benefits of the
binding model. Using simple XAML expressions you can bind controls to properties deep down in your object graph. However, sometimes you need to do something a little more complicated. If you have use data templates for list controls you may have found the need to bind to something that’s way up the visual tree. Below is a good example of this.
<Button Command="{Binding RelativeSource={RelativeSource FindAncestor, AncestorType={x:Type UserControl}}, Path=DataContext.AddPersonComand}"/>
In this scenario I have bound a button command to a command definition which sits on my presenter. However, you will notice I made a deliberate mistake. I spelt the word command wrong in the path. As a result WPF will fail to locate the binding and when I actually click on this button nothing will happen. This is frustrating and there things I can do to identify this issue. Bea Costa has some good posts around this topic
here. The problem with these approaches are that none of them are particularly obvious to the developer.
What I would really like is to be able to throw an exception whenever a binding fails. I would also like to show debug statements printed in my output window when a binding access occurs. As I already have a substantial codebase that I do not have the time or urge to go through in order to support this functionality I want to do it in a low impact way.
Building the Dynamic Binding Interceptor
When we look at how I bind my presenter you can see it’s a fairly simple affair. My view Implements IBindableView which exposes the Views DataContext to the presenter. Therefore it’s a trivial process for creating the binding.
View.DataContext = this;
It at this point where I would like to attack the problem at hand. As dynamic objects use
dynamic dispatch to query a type, my best approach is to set the views data context to be a dynamic object of my choice and then route the requests to my presenter. The key thing here is that I do not want to change my existing presenter code in anyway. I want my binding code to look like this.
View.DataContext = new BindingInterceptor(this);
Given that, I need to create my new interceptor class and implement the behaviours I mentioned. To do this we need to create a new class that inherits from
DynamicObject and provide a constructor which takes our source for binding. This class is show below.
///
/// Provides interception of properties for bound objects.
///
public class BindingInterceptor: DynamicObject
{
protected dynamic Source{ get; set;}
public BindingInterceptor(dynamic source)
{
Source = source;
}
}
You can see that we store the source for future use. The interception of properties will be achieved by overriding two methods on DynamicObject. These are shown below.
public override bool TryGetMember(GetMemberBinder binder, out object result)
{
return base.TryGetMember(binder, out result);
}
public override bool TrySetMember(SetMemberBinder binder, object value)
{
return base.TrySetMember(binder, value);
}
These two methods will be invoked whenever our View tries to access a property on its data context, which in our case will be the our BindingInterceptor. It would be a simple task to implement the desired behaviour of logging and throwing exceptions within our BindingInterceptor, however on this occasion I would like something a little more flexible. Instead I would like to be able to instruct the BindingInterceptor of the behaviours I would like it to execute before and after accessing a property. Looking back at our binding code, I would now rather it looked more like the following.
bindingInterceptor
.OnGet
.BeforeGet((binding) => Debug.WriteLine(string.Format("TRY GET: Name={0}", binding.Name)))
.AfterGet((binding, value) => Debug.WriteLine(string.Format("GET RESULT: Name={0}, Value={1}, Result={2}", binding.Name, value, "Success")))
.IfGetException((binding, exception) => { throw new BindingException(string.Format("Failed to Get [{0}]", binding.Name), exception); })
.OnSet
.BeforeSet((binding, value) => Debug.WriteLine(string.Format("TRY SET: Name={0}, Value={1}", binding.Name, value)))
.AfterSet((binding, value) => Debug.WriteLine(string.Format("SET RESULT: Name={0}, Value={1}, Result={2}", binding.Name,value, "Success")))
.IfSetException((binding, exception) => { throw new BindingException(string.Format("Failed to Set [{0}]", binding.Name), exception); });
Although this code is more verbose, it does allow me to specify exactly what I would like implemented on access of properties. It also uses a fluent interface which to a reader who is new to the code should be relatively easy to follow. In order to implement this in our BindingInterceptor we need to add a few simple methods which will take an Action as their input and return an instance of the BindingInterceptor. These methods are shown below.
public BindingInterceptor OnGet { get { return this; } }
public BindingInterceptor OnSet { get { return this; } }
public BindingInterceptor BeforeGet(Action<GetMemberBinder> beforeGet)
{
BeforeGetPropertyDelegate = beforeGet;
return this;
}
public BindingInterceptor AfterGet(Action<GetMemberBinder, object> afterGet)
{
AfterGetPropertyDelegate = afterGet;
return this;
}
public BindingInterceptor BeforeSet(Action<SetMemberBinder, object> beforeSet)
{
BeforeSetPropertyDelegate = beforeSet;
return this;
}
public BindingInterceptor AfterSet(Action<SetMemberBinder, object> afterSet)
{
AftersetPropertyDelegate = afterSet;
return this;
}
public BindingInterceptor IfGetException(Action<GetMemberBinder,Exception> getException)
{
GetExceptionDelegate = getException;
return this;
}
public BindingInterceptor IfSetException(Action<SetMemberBinder,Exception> setException)
{
SetExceptionDelegate = setException;
return this;
}
Now we have the ability to inform the BindingInterceptor of the behaviours we would like it to carry out, the final task for us to do is make sure that the these behaviours are invoked and that the value is marshalled to and from our source presenter. I have highlighted this below.
private void GetValue(GetMemberBinder binder, out object result)
{
try
{
if (BeforeGetPropertyDelegate != null) BeforeGetPropertyDelegate(binder);
Type type = Source.GetType();
result = type.GetProperties().FirstOrDefault(p => p.Name == binder.Name).GetValue(Source, null);
if (AfterGetPropertyDelegate != null) AfterGetPropertyDelegate(binder, result);
}
catch (Exception exception)
{
if (GetExceptionDelegate != null) GetExceptionDelegate(binder, exception);
}
}
private void SetValue(SetMemberBinder binder, object value)
{
try
{
if (BeforeSetPropertyDelegate != null) BeforeSetPropertyDelegate(binder, value);
Type type = Source.GetType();
type.GetProperties().FirstOrDefault(p => p.Name == binder.Name).SetValue(Source,value,null);
if (AftersetPropertyDelegate != null) AftersetPropertyDelegate(binder, value);
}
catch (Exception exception)
{
if (SetExceptionDelegate != null) SetExceptionDelegate(binder, exception);
}
}
To test our BindingInterceptor I need to create a simple user interface. I want to be able to bind two presenters, one good presenter that meets all the requirements of the bound controls and one bad presenter that wont.
When we click the “Bind good presenter” option we use our BindingInterceptor to wrap our presenter instance and then set this as the data context of the window. Doing this provides us with the following output in the debug window.
----------------BEGIN GET--------------------
TRY GET: Name=LikeDynamics
GET RESULT: Name=LikeDynamics, Value=True, Result=Success
----------------END GET----------------------
----------------BEGIN GET--------------------
TRY GET: Name=WantToSeeMore
GET RESULT: Name=WantToSeeMore, Value=True, Result=Success
----------------END GET----------------------
----------------BEGIN GET--------------------
TRY GET: Name=Comments
GET RESULT: Name=Comments, Value=Good presenter is bound., Result=Success
----------------END GET----------------------
You can see the initial binding of the data context causes our control bindings to refresh the values from their source. Each of these requests is serviced via our BindingInterceptor. If we then uncheck the “I like .net 4.0 dynamics?” checkbox we can see the value being passed from the windows through our interceptor and into our good presenter.
----------------BEGIN SET--------------------
TRY SET: Name=LikeDynamics, Value=False
SET RESULT: Name=LikeDynamics, Value=False, Result=Success
----------------END SET----------------------
----------------BEGIN GET--------------------
TRY GET: Name=LikeDynamics
GET RESULT: Name=LikeDynamics, Value=False, Result=Success
----------------END GET----------------------
Now we have met the first objective of our interceptor class. We have provided a level of logging without having to change our existing presenter code. Our second objective was to raise exceptions when a binding fails. We do this by selecting the “Bind Bad Presenter” option which does not have the properties required for binding.
----------------BEGIN GET--------------------
TRY GET: Name=LikeDynamics
System.Windows.Data Error: 17 : Cannot get 'LikeDynamics' value (type 'Object') from '' (type 'BindingInterceptor'). BindingExpression:Path=LikeDynamics; DataItem='BindingInterceptor' (HashCode=7063836); target element is 'CheckBox' (Name=''); target property is 'IsChecked' (type 'Nullable`1') BindingException:'DynamicInterceptor.BindingException: Failed to Get [LikeDynamics] ---> Microsoft.CSharp.RuntimeBinder.RuntimeBinderException: Cannot perform runtime binding on a null reference
This time we can see that the request to read the property “LikeDynamics” fails with an Binding exception. This is as expected as we defined this in our BindingInterceptor behaviours. However, unfortunately for us the application does not raise any exceptions and therefore the binding is invisible. This is NOT what we want. The reason this occurs is due to the fact that when WPF attempts to access a binding it is wrapped in an TryCatch block and the exception is hidden. As part of this post I did take the time to look through the .NET source code and actually found the code where this occurs. I noticed that all exceptions are ignored accept a number of Critical exception types. These exceptions such as StackOverflow, OutOfMemory, NullReference are the only ones which will bubble up to the surface. Therefore If I want my custom binding exception to be raised, I need to ensure the exception inherits from NullReferenceException. Making this small change and rebinding to the bad presenter now causes an exception to be thrown.
Conclusion
In this post I wanted to introduce a new approach to proxying using c# 4.0 dynamics. This simple example should have provided you with a good insight into interception techniques. From there it opens the door for whole range of exciting opportunities to solve complex problems. You can see the code required to implement this pattern is minimal. I plan to follow up this post with a series of posts which will outline some cool uses for dynamic interception in a range of problems. This approach can be used for both Silverlight and WPF as Microsoft are making great efforts to support dynamics across technologies.
If you want the source code for this post you can download it
here.