As I mentioned in a previous article, there are multiple dependency injection frameworks our there for .net framework. Here, we will be talking a bit about the most popular ones and show very simple examples of how to get started with them and how to use them.
This is not an exhaustive list! There are MANY frameworks out there. These are just a few I have experimented or worked with.
I’ll be going over how to create your inversion of control container (IOC Container), how to make simple registrations and resolve them. In the end, I’ll write a few words on which of the many dependency injection frameworks you should use.
For all the frameworks I will be talking about, you can add them to your project by simply searching for their name (no spaces) on nuget. Make sure to install them if you are following these examples. Finally, let’s assume you have a class called SQLRepository you want to bind to the interface IRepository. Let’s get to it!
Ninject
Ninject is the framework I am most acquainted with. While it is quite feature rich, it is also reasonably slow.
In Ninject’s world, the container is called a kernel. You can instantiate a kernel as such:
var container = new StandardKernel();
In order to bind SQLRepository to IRepository, just write the following:
container.Bind<IRepository>().To<SQLRepository>();
Finally, if you want to resolve an instance of IRepository,
var repo = container.Get<IRepository>();
StructureMap
StructureMap is the oldest dependency injection framework for .net out there.
In order to create your container, you must do the following.
var container = new Container();
StructureMap puts some focus on instantiating the container in one blow, since that is usually considered best practice. Therefore, they provide you with the Configure method on the container, where all the configuration should happen. You would register the repository like this:
container.Configure(c => c.For<IRepository>().Use<SQLRepository>());
Finally, in order to resolve an instance of the IRepository,
var repo = container.GetInstance<IRepository>();
Simple Injector
Simple Injector is one of the newer dependency injection frameworks out there. According to them, one of their main goals is to provide a lightweight library with a lean API, deprecating old ways of doing things such as file based configuration.
Instantiating the container is rather similar to the other two:
var container = new Container();
Once you have the container, you can register your implementations as such:
container.Register<IRepository, SQLRepository>();
Resolving is done just like StructureMap
var repo = container.GetInstance<IRepository>();
Conclusion
Small disclaimer: I have only extensively worked with Ninject. I have played a bit around with StructureMap and Autofac as well, but nothing compared to Ninject.
As you can see, all of the given examples are rather similar in regards to how you can achieve simple container configuration. Feature wise, most frameworks also supply all the features you will need in order to instantiate your object graph. Documentation is not lacking on any of them either: they have very extensive, very rich documentation.
Simple Injector has this design philosophy of pushing their developers into good code design by scrapping features that often lead brittle code, which is one of the reasons it’s not as feature rich as some of the others (but still, quite a feature rich framework).
But they are kinda right. Complex object graphs are usually an indication of code smell and bad design. You should use this as a tool for detecting bad design decisions and fixing them before it’s to late.
If you are interested in performance numbers, have a look from a performance test done by palmmedia.dk
While it is true that server side applications usually have ample amount of time in order to properly initialize themselves, having performance in mind is a good idea when developing client side applications or other applications where the dependency graph needs to be resolved often. This could be a ASP.NET application where it’s controllers have something similar to a per-request lifetime. Even when that’s not the case, developing the application, as well as running integration tests, would usually feel much better on an application that starts up faster then slower (duh).
Honestly, the next dependency injection framework I’ll have a look at next time around is Simple Injector, because of the fact that it is pretty fast, is quite feature rich and has great documentation.
1 thought on “Dependency Injection: Frameworks”