The Castle project contains a library called DynamicProxy. As the name says, the aim of this
library is to provide functionality to create dynamic proxies at runtime. The problem is that the
documentation for this is not very complete and examples are rare or do not fit the needs
for beginners. Therefore I want to write here what I’ve learned so far. For this we’ll stick to the
simple ITask example from the last blog.

So, let’s have a look, how this could be helpful, to avoid hand written proxies. The first question
that arises is, how can a proxy be constructed at runtime?  This is done by using the classes
provided by the System.CodeDom and System.Reflection namespaces of the .net framework.
We’ll leave it to this, since the details of the implementation aren’t really interesting, when using
the library. The only interesting thing right now is, that we can build an proxy object for any
existing class. This is done with the

class. But before we go further, there is one big thing to think about. In the TaskProxy from
the last blog, we have implemented our own version of the doExecute() method, where we
checked, if a user is allowed to execute a task or not. If we now have a dynamicly constructed
proxy, generated by the ProxyGenerator, how can we provide our own implementation for it?
There must be a way to step in the execution process of the method. Without this possibility
everything else makes no sense. So thats why the methods from the ProxyGenerator want
some additional parameters:

We have to provide one (or more) objects that implements the IInterceptor interface.  This
interface is defined in the Castle.Core.Interceptor namespace and is exactly what we are
looking for, because this is the place, where our own proxy implementation lifes. To achieve
this, we only have to implement one single method:

As parameter an IInvocation - object is provided. This gives us some importand informations
about the current execution. Since we don’t override a specific method, we have to know wich
method is currently executed and what parameters are stated to the call. Furthermore we need
access to the real TaskImpl object and maybe have to set return values etc. All this could be
done using the invocation properties. The definition looks like this:

Beside this we can see a call to a Proceed() method. With this call we simply allow the proxy to
continue the actual called method.

We can run our test from the last blog now. Let’s stop after the proxy was generated. We can see
the following result:

As we can notice, the returned object is a randomly generated typename for the proxy.
Let’s make another breakpoint at the Intercept method. What happens?
To our disappointment nothing really happens So what’s wrong here? The answer to this is
simple. As mentioned above, the proxy is generated using System.CodeDom. That means a new
type is build in memory with implementations for all methods and properties of the base class,
wich is TaskImpl in our case. The so created proxy class inherits from TaskImpl and tries
to override the methods to allow interception. Doing this, the same rules are effective as when
we would do this by hand.  This means to override a method in an inherited class, the method
has to be virtual in the base class. So let’s change our TaskImpl class and try it again:

That’s better. The call to invocation.Proceed() now simply continues the doExecute()
method of our TaskImpl class. Putting it all together, we can now implement our proxy
behaviour, as we did in the last blog:

The TaskProxy is no longer needed and our tests run succesfully:

In the end this is a quick overview of how to use DynamicProxies. There is a lot more to
talk about, but I think it is agood starting point for using the library and to understand, how
proxies are generated and what one can do with it.

To see exactly what happens behind the scene, you can make the proxy persistent and have
a look at it using .NET Reflector. To do this, simply call:

Now open the resulting assembly in the .NET Reflector. Here you can see the generated class
for the proxy and what is done to the doExecute() method.

“…A proxy, in its most general form, is a class functioning as an interface to something else…”

In practice this short definition means, a proxy encloses a real object in its entirety but presents
the same signature to the client. So a client must not know if he works with the proxy or
the real object. This is very usefull in a lot of cases, since you build an interface to a class and
can extend the functionallity and  behaviour of it, without changing it’s original implementation.

The example above shows an proxy that implements the ITask interface and delegates all calls
to one of the interfaces methods to an internal instance of a TaskImpl - object.

The factory:

The client:

Ok, the proxy hides the real implementation, but furthermore it does nothing real useful. If we start
a task, it is simply executed. But what about for instance permissions and dependencies? Not every
user can execute every task, I think this is common for every application. So where can we validate
if the user is allowed to execute a specific task? The TaskImpl is not a good place for this I think,
since there only the execution logic should be implemented.  I would prefer implementing this in the
proxy. Since every ITask - object is created by a factory, it is easy to interfere the process of creating
an ITask instance and put the proxy on job.

We use a simple User class to emulate the permission validation:

The TaskImpl stays untouched, but the proxy implementation of doExecute now looks like this:

The task will be only executed, if the User has the permission to do this. Instead of throwing an
exception it also could simply return false.

Now we can run two simple tests with it:

As we can see, all test are successful:

So finally this simple example shows, what problems can be solved using proxies. As we can see,
the client stays completly untouched and the TaskImpl too.

But thinking of real world applications, interfaces and classes are useally complex an have lots of
properties and methods. It would be worse to code proxies for it by hand. In the end there is no need
to do this, because there a libraries out there, doing the job very good. But thats for the next part…