Ultimate Interface Segregation: Dependency injection by Delegate
I've been on a bit of a tear about declaring dependency contracts and injecting only what is required. While examining the use of Interfaces in IoC and their shortcomings, I decided that taken to the extreme, dependencies come down to call dependencies, which could be modeled with delegates rather than interfaces. Instead of writing a novel, as I've been prone to, i thought I'd do a shorter post on my approach to this solution, and expand on the implementation in later posts.
To recap, in the SOLID principles, the Interface Segregation Principle states: Clients should not be forced to depend upon interfaces that they do not use. This means that interfaces should be fine-grained enough to expose no more than one responsibility. Taken to the extreme, this could be taken to mean that each interface only has a single method. There are valid SRP scenarios where a responsibility is modeled by more than one call, but let's start with the simplest scenario first, then see how well it applies to more complex responsibilities later.
In C# we have delegates, which describe a single method call. A delegate instance is a reference to a method that encapsulates a specific instance of a class, without exposing the underlying class (unless your delegate is a static method). A delegate can even be used to expose internal, protected and private methods.
Instead of declaring a list of interfaces that the IoC container should inject, classes would define their dependencies as delegates. Taking the example from my duck typing post, we would get the following dependency declarations.
First, we have the same service provider, MessageQueue, which still doesn't need to implement an interface:
public class MessageQueue
{
public void Enqueue(string recipient, string message) { ... }
public string TryDequeue(string recipient) { ... }
}
Next, we have the new
Producer, now declaring its dependency has a delegate:
public class Producer : IProducer
{
public delegate void EnqueueDelegate(string recipient, string message);
public Producer(EnqueueDelegate dispatcher) { ... }
}
And finally, we have the new
Consumer, also declaring a delegate for construction time injection:
public class Consumer : IConsumer
{
public delegate string TryDequeueDelegate(string recipient);
public Consumer(TryDequeueDelegate inbox) { ... }
}
Think of the delegate as your Method Interface. You could define your dependencies as Func's and Action's, but that would obfuscate your dependencies beyond recognition in most scenarios. By using an explicit delegate, you get to attach the dependency to the class that has the dependency, in addition to having a descriptive signature.
Now, if we were to wire this up manually we'd get something like this:
var queue = new MessageQueue();
IProducer producer = new Producer(queue.Enqueue);
IConsumer consumer = new Consumer(queue.TryDequeue);
That's simple enough, but not really very scalable, once you get a lot of dependencies to wire up. What we really need is an IoC container that let's us register delegates against classes, instead of having to have instances at dependency declaration time. Delegates can't be cast from one to another and are not, strictly speaking, types, which posts some challenges with creating a type-safe registration interface. There are a number of ways to accomplish this syntax, which I will elaborate on in
my next post.
Labels: c#, delegate, IoC, SOLID
DynamicProxy rocks!
Recently, I've had a need to create proxy objects in two unrelated projects. What they had in common was that they both dealt with .NET Remoting. In one it was traditional Remoting between machines, in the other working with multiple AppDomains for Assembly flexibility. In both scenarios, I had a need for additional proxies other than the Remoting created Transparent proxy and the
Castle project's
DynamicProxy proved invaluable and versatile. It's a bit sparse on documentation, but for the most part, you should be able to figure things out by playing with it and lurking around their
forum.
If you're not familiar with the Castle project, check it out, because DynamicProxy is really only a supporting player in an excellent collection of useful tools. From their Inversion of Control Containers MicroKernel/Windsor to MonoRail and ActiveRecord (built on NHibernate), there is a lot there that can make your life easier.
But why would I need to create proxies, when the Remoting infrastructure in .NET takes care of this for you with Transparent Proxies? Well, let me describe both scenarios:
Resilient Client/Server operations with Remoting
From my experience with .NET Remoting, it's dead simple to do something simple. But it really is best suited for WebService stateless calls, because there isn't a whole lot exposed to add quality of service plumbing. The transparent proxy truly is transparent until something fails. Same is true on the server side, where you don't get a lot of insight into the clients connected to you.
And then there are events, which, imho, are one of the greatest thing about doing client/server programming with Remoting. Those are painful in two ways, having to have a MarshalByRefObject helper proxy the event calls and pruning dead clients on the server which you won't find out about until you try to invoke their event handler.
But those shortcomings are not enough reason to fall back to sockets and custom/stateful wire protocols. Instead I like to wrap my transparent proxy in another proxy that has all the plumbing for maintaining the connection, pinging the server and intelligently handling failure. Originally I created them by hand, but I just converted my codebase over to use DynamicProxy the other day.
Using CreateInterfaceProxyWithoutTarget and having the proxy derive from my plumbing baseclass automagically provides me with an object that looks like my target interface by wraps the Remoting proxy with my quality of service code.
public static RemotingClient<T> GetClient(Uri uri)
{
Type t = typeof(T);
ProxyGenerator g = new ProxyGenerator();
ProxyGenerationOptions options = new ProxyGenerationOptions();
options.BaseTypeForInterfaceProxy = typeof(RemotingClient<T>);
RemotingClient<T> proxy =
(RemotingClient<T>)g.CreateInterfaceProxyWithoutTarget(
t, new Type[0], options, new ProxyInterceptor<T>());
proxy.Uri = uri;
return proxy;
}
I'll do another post later just on Remoting, since the whole business of getting events to work was a bit of a labor and isn't documented that well.
Loading and unloading Assemblies on the fly
The second project started with wanting to be able to load and unload plug-ins dynamically and has now devolved into a framework for auto-updating components of an App at runtime.
This involves loading the assemblies providing the dynamic components into new AppDomains, so that we can unload the assemblies again by unloading the AppDomain. Instances of the components class are then marshaled across the AppDomain boundary by reference so that the main AppDomain never loads the dynamic assembly. This way, when a component needs to be updated, I can dump that AppDomain and recreate it.
The resilience of the connection isn't in question here, although there is need for quite a bit of plumbing to get references to the remoted components disposed before the AppDomain can be unloaded. Again, a DynamicProxy can help on the main AppDomain side by acting as a facade to the actual reference, so that you can reload the underlying assembly and recreate the reference without the main application having to be aware of it.
But I haven't gotten that far, nor have I decided whether that would be the best way, rather than an explicit disposal and recreation of the references.
Where DynamicProxy comes to a rescue here is when your object to be passed across the boundary isn't derived from MarshalByRefObject. This could be a scenario, where you are trying to use a component that's already derived from another baseclass, so adding MarshalByRefObjectisn't an option. Now DynamicProxy with its ability to provide a baseclass for the proxy gives you a sort of virtual multiple inheritance.
This is also an ideal scenario for using Castle.Windsor as the provider of the component. Using IoC, I was able to create a generic common dll that contains all the interfaces as well as a utility class for managing the components that need to be passed across the boundary, this class never has to know anything about the dynamic assembly, other than that the assembly stuffs its components into the AppDomain's Windsor container.
The resulting logic for creating an instance that can be marshaled across AppDomain boundaries looks something like this:
public T GetInstance<T>()
{
Type t = typeof(T);
if (!t.IsInterface)
{
throw new ArgumentException("Type must be an interface");
}
try
{
T instance = container.Resolve<T>();
if (typeof(MarshalByRefObject).IsAssignableFrom(instance.GetType()))
{
return instance;
}
else
{
ProxyGenerator generator = new ProxyGenerator();
ProxyGenerationOptions generatorOptions = new ProxyGenerationOptions();
generatorOptions.BaseTypeForInterfaceProxy = typeof(MarshalByRefObject);
return (T)generator.CreateInterfaceProxyWithTarget(t, instance, generatorOptions);
}
}
catch (Castle.MicroKernel.ComponentNotFoundException)
{
return default(T);
}
}
All in all, DynamicProxy is something that really should be part of the .NET framework. Proxying and Facading patterns are just too common to only support them via the heavier and MarshalByRefObject dependent remoting infrastructure.
The version of DynamicProxy I was using was DynamicProxy2, which is part of the Castle 1.0 RC3 install. It's a lot more versatile than the first DynamicProxy and deals with generics, but mix-ins are not yet implemented in this version. However, if you just need a single mix-in, specifying the base class for your proxy can go a long way to solving that limitation.
Labels: AppDomain, Castle, Dynamic Proxy, IoC, Remoting
