This post is going to contain some content which will be relevant to a future post that I plan to do about my architecture for the HomeLibrary example application that I’m working on.
It involves using the dynamic runtime in .NET to do some pretty cool runtime binding.
First, a really quick example using the dynamic runtime. For those who are unaware of it, the dynamic runtime is not an alternative to the CLR, but something which runs on top of it and is able to provide dynamic binding, instead of the static binding which we are familiar with.
Take the following code:
dynamic someList = new List<string>();
someList.Add("I got added to the list");
foreach (var str in someList)
{
Console.WriteLine(str);
}
someList = DateTime.Now;
Console.WriteLine(someList.ToString());
The two important principles, in my mind, which can be taken away from that are:
- you have dynamic typing, which resembles that which we see in Javascript;
- the methods which are invoked on those dynamic references are bound dynamically at run-time, as distinct from at compile time.
That second one is the one which really sets it apart from the var keyword.
var – compile-time binding
dynamic – runtime binding
As you could imagine, this opens up a raft of possibilities. I’m now going to show an example which is a good demonstration of how this can be used.
The problem which I will address in the next example is something very real and common if you want to decouple various objects in your architecture. Let’s say I have a whole swag of Validators. They all implement IValidator<T>. They do their work inside a method called Handle, which is a method on an single object called Handler. So, to clarify, there is not a discrete, strongly typed handler for each Validator. There is one handler which uses all Validators, depending on the command which is passed in to that Handle method.
If it were strongly typed, it would look something like this:
public void Handle(MyCommand command)
{
IValidator validator = new Validator<MyCommand>();
var result = validator.Validate(command);
// etc.
}
But as you can see, to make this work I’d have to create a Handle method for every single command which would each use their own validator. OR, I could do something like this:
public void Handle(TCommand command)
{
Type validatorType = typeof(IValidator<>).MakeGenericType(command.GetType());
var assembly = Assembly.GetExecutingAssembly();
Type concreteType = null;
foreach (var exportedType in assembly.GetExportedTypes())
{
if (validatorType.IsAssignableFrom(exportedType))
concreteType = exportedType; break;
}
var constructors = concreteType.GetConstructors();
dynamic validator = constructors[0].Invoke(new object[] { });
var validateResult = validator.Validate(command);
// etc.
}
You can see the Validate method is bound at runtime to the concrete object that is resolved by reflection. If the TCommand is a MyCommand object, then the Validate method of the MyCommand object is what will be invoked; and importantly no casting required.
And this code becomes even briefer if I use a dependency injection library:
public void Handle(TCommand command)
{
Type validatorType = typeof(IValidator<>).MakeGenericType(command.GetType());
dynamic validator = _container.Resolve(validatorType); // _container is a private class-level variable
var validateResult = validator.Validate(command);
// etc.
}
So you can see, the dynamic runtime becomes very useful when used in conjunction with reflection and/or your favourite IOC. This will greatly reduce the number of classes/methods you need to write, which alleviates the maintenance burden.
There is a trade-off. Use of the dynamic runtime incurs a penalty hit. On modern hardware, however, this is negligible. But if sheer performance is what is required by your application, then you may not be able to take advantage of the dynamic runtime (in the same way that you probably don’t want to use reflection).
