Unleashing modules

I’m a big fan of the Autofac IoC-container, it’s pretty light weight, blazingly fast and very object oriented. One of the features I love the most is the ability to divide the boot strapping code into modules. Also, to set up your dependencies in code with a fluent interface rather than in an xml-file is great in so many ways (intellisense and refactoring to name a few). The one problem I’ve found with this is that it couples your assemblies tighter than they might need to be coupled.

The problem

Let’s consider this example: We have an application that makes use of the service IFoo, this interface is defined in the assembly FooAssembly. There is an implementation of the IFoo-interface called XmlFoo in the XmlFooAssembly and this implementation is the implementation we want to use in our application. The implementer of the XmlFooAssembly has been nice enough to provide a module that registers the XmlFoo as an IFoo and also registers services that the XmlFoo-implementation itself is dependent upon. This is quite nice since now, in our boot strapping code what we have to do is to register that module along with any other registrations we have, something like this:

var builder = new ContainerBuilder();

builder.RegisterModule(new MyApplicationDependencyModule());
builder.RegisterModule(new XmlFooDependencyModule());

var container = builder.Build();

 

This is all pretty nice and clean, not much of a problem right? Well, there is one problem with this, in order for us to register the XmlFooDependencyModule we have to have a reference to the assembly where it’s defined (XmlFooAssembly) from our application assembly, note that this is the only place we need this reference, in all other places we’re programming against the abstraction IFoo, not the XmlFoo. This couples the assemblies more tightly than they need to be. It’s not that this is a giant problem, and it can be solved by using xml-configuration of dependencies rather than using the module directly, however, another problem with this is that if we’re using the same dependencies in multiple applications we have a lot of boiler plate code in that is duplicated along applications.

Your going to fix this are you?

Well, yeah, there is a point with this blog post. I guess you’re familiar with MEF (Managed Extensibility Framework), if not go read up on it, it’s a very cool technology. My idea is that we could use MEF to export the modules from the assemblies that implement them and import them in the application that uses them, this way we can remove the reference to the XmlFooAssembly. Instead of registering the modules we know exists, we register all modules that are “magically” imported. To do this I created a new module type that inherits the Autofac.Builder.Module-class and is called ComposedModule. You can for example instantiate the module with a path to a directory that contains a number of assemblies, the composed module will then (through MEF) find all the exported modules in the assemblies in the folder. When you register this composed module in your builder it will register all the imported modules in the builder:

var builder = new ContainerBuilder();

builder.RegisterModule(new ComposedModule(@"c:\MyApplicationDirectory"));

var container = builder.Build();

 

You could actually give the ComposedModule a MEF-catalog instead of the directory path and the ComposedModule will use this catalog to load the exported modules:

var builder = new ContainerBuilder();

builder.RegisterModule(new ComposedModule(new AssemblyCatalog(this.GetType().Assembly)));

var container = builder.Build();

A blog post about the implementation details and some other features of the ComposedModule is coming in the next few days so please check back for that.

If If Then Throw New CodeSmellException()

I’ve had this – somewhat controversial – opinion for a long time, that if you have an if-statement there’s something wrong with your design. Of course this is taking it a bit too far, but I think that the initial reaction for any developer that finds her-/himself writing an if-statement should be “could I do this differently”.

The last week I’ve been leading a new team and we’re starting a new project and we’ve been building a prototype for the product we’re going to build. It’s an API intended for internal use and I can’t talk to much about it but it’s not a trivial piece of software. It handles going out to external systems, aggregating answers from them, displaying the information in a UI and let’s the user communicate back to the external systems with additional information. The prototype has maybe something like twenty classes and a couple of hundred lines of code, now here’s the point of this whole post: this Thursday when at least 90% of that code was already written we wrote our first if-statement. I called it out “there it is!”. The other developers were like: “what?”. “-That’s our first if-statement”. The prototype is done and there is still one single if-statement in it, and it’s not that we’ve been trying to avoid it, we’ve just designed with the SOLID-principles in mind which leads to a more sound and less complex architecture.