Dependency injection (DI) is an important topic to consider when building a .NET application (or any for that matter). It is difficult to argue the benefits… testability, loose coupling, and so on. If only choosing an IOC container were as simple as deciding to use DI :).
Over the years, StructureMap has been my go to container. It has a lot of nice registration features and the performance seemed good enough. I’ve also used Unity, Autofac, and Ninject which offer similar features and performance.
This time, I decided to take a bit of a different approach…
Performance & Features
When looking for an IOC container, this link always seems to come to the top of my google searches. The analysis is in-depth and there is a great comparison of feature sets and performance. I highly recommend scrolling through!
After taking a close look, I realized the containers I usually gravitate towards were either average or slow from a performance perspective. I have worked on a lot of high transaction applications so for me, average performance won’t do!
It seemed as though I was faced with a decision.
Should I use a feature rich container like StructureMap or Ninject at the cost of performance? Or should I go all in for speed and use a container like DryIoc?
Paper or plastic? Debit or credit? Features or speed?
And then it dawned on me…
Features AND Performance
I tend to use my IOC containers in a relatively simple way. There are a few pieces that I rely on and would never want to implement myself.
- Instantiating objects (efficiently)
- Handling life-cycles
- Managing dependencies
The remaining pieces are where the convenience features lie.
- Type Scanning
- Convention based registration
As it turns out, implementing these features is actually quite simple. Being the control freak that I am, I love the flexibility this allows. With this in mind, I decided to use the absolute fastest container and handle all the type registration on my own.
Check out my next post (coming soon) on how I implemented DryIoc!