DI – Constructor Injection, Bootstrapping

by EFVincent on 06/24/2011

I recently blogged about the Practical Dependency Injection 101, then DI, testing and mocking. In this post I’ll get into the concept of bootstrapping as it relates to dependency injection.

Constructor Injection

The idea of dependency injection is that classes are defined such that any dependencies on other classes or services, are injected into the class by some external mechanism, as opposed to being “newed up” directly. The most common form of DI is constructor injection, where a class defines a constructor that has as its parameters the external dependencies required by the class.

There are several benefits to this particular method of injection; the most obvious is that in a well designed system the dependencies of a class are clearly visible in the constructor. In the DI 101 post a data provider was defined like this:

public class DevDataProvider : IDataProvider {
    private readonly IIdentService _identService;
    private readonly ILogService _logSvc;
    private static readonly List<Employee> EmployeeStore = new List<Employee>();

    public DevDataProvider(IIdentService identService, ILogService logSvc) {
        if (identService == null) throw new ArgumentNullException("identService");
        if (logSvc == null) throw new ArgumentNullException("logSvc");
        _identService = identService;
        _logSvc = logSvc;

    // Remaining implementation omitted for brevity

The constructor is on line 6. From this constructor we can see that the DevDataProvider has dependencies on an IIdentityService and an ILogService. There should be no other dependencies in the class other than to well known, stable libraries like the BCL.

There are other advantages to using constructor injection. Should the list of dependencies get too long, say longer than four parameters, you’ve got a code smell that perhaps the class is doing too much, violating the single responsibility principal.


In order to be able to resolve dependencies, the DI container must be configured. This set up is done during the bootstrapping phase. Typically this only needs to be done once, but changes to the container make sense in some scenarios like when a DI container is being used to support extensions or plug-ins. In that case components might be added or removed from the DI container while the app is running. These scenarios are out of scope for this post.

The container may be configured in several ways – Auto configuring, configuration in code, and configuration files (typically XML / app or web.config files). My current favorite DI framework is AutoFac, and I typically configure in code, but different projects will have different demands, so familiarize yourself with the specifics of your selected framework and understand the tradeoffs involved in the different types of configuration. You can even configure the DI container using more than one method – perhaps Auto configuring for the bulk of the registrations, then code or XML for more specific configuration needs.

Bootstrapping a Console Application

Depending on the type of application you’re working on, there are specific places for bootstrapping to take place. The place to do configuration and bootstrapping is sometimes referred to as the composition root (you can read about these concepts in more detail in Mark Seeman’s Dependency Injection book, published by Manning).

In a console application, the static Main() method is a typical place to configure the container. While we rarely write console apps in production (at least I rarely do), the simplicity makes it easy to see the implications of the bootstrapping procedure.

In the following sequence diagram, in step one [1] the Main() entry point is called on the console application. Main() is serving as the composition root. From there a private Bootstrap() methods is called [2] and the DI container is configured. The exact mechanism varies by framework.


Once the container is configured, the main entry point requests that the DI container resolve the App type [3]. The DI container creates whatever dependencies are required by the App [4]. This happens hierarchically; dependencies may themselves have dependencies and so on. The DI container sorts all this out and is also responsible for lifetimes of create objects etc. The DI container can create and return the instance off the App [5]. The Main() function can then pass control to the app [6] which will leverage the injected dependencies [7] to do the real work.

Only Directly Reference the DI Container in the Bootstrapper

This is an important point, and if you get nothing else from this post, understand this.

  • The DI container is configured in the composition root (Main() in this case)
  • The DI container is used to resolve or build the App
  • The app is then run to do the work

Once the app is instantiated, it should have all of its dependencies injected. The app should not have a reference to the DI container! If we allow the app or any of its dependencies to have access to the container, then several bad things happen:

We’ve taken on a dependency to the DI Container itself

Yes its true that the assembly has a dependency on the DI container. But for purposes of this discussion the assembly is not the application. The App class and the services (other classes) it depends on is the application. We don’t want to take a dependency on the DI container in those classes; rather, we should be able to switch to a different DI container if needed and not effect the App and the dependent services.

In any kind of a significant application the app’s classes would be in a different assembly, and services might be scattered across even more assemblies, and those should not have  a dependency on a DI container. They should however be designed and built with the DI pattern in mind – with the dependencies specified in the constructor, with references to abstract types or interfaces, rather than to concrete implementations.

We’re hiding a dependency inside the App

Earlier I mentioned that a benefit of constructor injection is that the dependencies are clearly visible (even documented if you will) in the signature of the constructor. We really don’t want to see lines like this buried in the methods of the classes:

// Anti-pattern - don't use DI container except
// in composition root

var dal = Container.Resolve<IDataAccessService>();

// And defintely don't do this

var dal = new SqlDataAccessService(connectString);

A class that that has these lines buried inside somewhere has hidden dependencies on both the DI container and IDataAccessService (or worse, by using the new keyword directly, on the SqlDataAccessService). These hidden dependencies undermine the benefits of using DI containers at all.

Bootstrapping in other Application Types

Other types of apps have different places for bootstrapping and application roots. Unlike a console app, an ASP.NET MVC 3 application isn’t top-down linear, the application must respond to web requests. It does so by creating instances of controllers, and calling methods on those controllers to respond to web requests.

A controller in MVC3 is like the app was in our console example above. It will be resolved, or created, by the DI container. Controllers are different in that there will likely be several different controllers in an MVC application. Also, we don’t get to resolve a controller and tell it to run right from the composition root, the ASP.NET MVC framework will be receiving web requests and will need to resolve controllers later, after bootstrapping.

In ASP.NET MVC 3 this is accomplished by providing a hook, or a place where we can supply a DI container for ASP.NET MVC 3 to use when creating controllers. The developer configures the DI container, and then wires that container into the MVC framework via an instance of IControllerActivator. In the case of AutoFac, there’s a NuGet package called AutoFac.Mvc3 that includes classes to integrate with MVC3. The implementation details are beyond the scope of this post – just DuckDuckGo AutoFac.Mvc and find a wealth of additional detail. Same goes for WCF, WPF, and Silverlight applications. There are best practices for configuring DI containers for each app type.

DI Unfriendly Application Types

Some application types just do not lend themselves very easily to dependency injection patterns. Classic ASP.NET pops into mind immediately. It was written before Microsoft was as willing to accept OSS, community driven concepts such as DI Containers. A big red flag with ASP.NET is that all subclasses to the Page class (which is what all your ASP.NET pages are) must have a parameterless default constructor. Well there goes parameter injection!

There are other mechanisms for implementing DI patterns in this case, but they’re sub-optimal. Again I’d refer you to Mark Seeman’s Dependency Injection book, which is far and away the best DI book in the .NET space, for advice and examples in dealing with DI unfriendly application types.

In Summary

Hopefully this was helpful in your understanding of a couple of key aspects of using DI containers. Practice a few console applications, and write some tests too. Once you get the idea, move on to more interesting application types. Before long you’ll be shocked you ever wrote applications without some degree of dependency injection. Yea – it’s that good for you.


My last post provided a brief introduction into dependency injection. To review, the example included a data provider for Employee objects, which included a feature to return the object corresponding to the currently logged in user. In the end the following interfaces were defined:

IDataProvider – the function is obvious from the name. One implementation, the DevDataProvider, uses a static List<Employee> as a data store.

IIdentityService – describes a service that supplies the current identity. What current is depends on the implementation of course. A concrete WindowsIdentService defines current as the currently logged in Windows user. The TestIdentService implementation always returned the same username, which is useful for testing as we will see.

ILogService – describes a simple logging service. The ConsoleLogService implementation prints logs to the console.

Dependency Injection &Testing

For this post I’ve added a standard MSTest project and a couple of tests for the data provider. The use of dependency injection patterns in the design of this simple example allows us to easily isolate the code under test.

static IContainer afContainer;

public static void TestInit(TestContext ctx) {
    var idSvc = A.Fake<IIdentService>();
    A.CallTo(() => idSvc.GetCurrentUserName())

    var bldr = new ContainerBuilder();
    afContainer = bldr.Build();

The test class has a static DI container instance, initialized in the class initializer. I’m using FakeItEasy to create a fake IIdentService at line five. Like six tells the FakeItEasy framework what to return when the GetCurrentUserName() method is called on the fake ident service. Having a fixed response makes testing the data provider a piece of cake.

I then register the fake ident service as well as a fake log service. For the log service, we don’t need to specify any behavior for the methods. The FakeItEasy framework will effectively sink any calls to the methods of the fake log service, which is fine for this test.

Lastly the data provider we want to test is registered with the DI container builder, and then container is built. The tests go on to use the DI container to resolve an instance of the data provider. The DI container will configure the data provider’s dependencies for a log service and an identity service with the fakes we built.

public void GetCurrentEmployeeTest() {
    var e = new Employee { WindowsUsername = "FAKE-ID" };
    var dal = afContainer.Resolve<IDataProvider>();
    var result = dal.GetCurrentEmployee();
    Assert.AreEqual(e.WindowsUsername, result.WindowsUsername);

This is just a small example of using a DI container in combination with a mock / fake framework for testing. The AutoFac DI container can handle much more complex scenarios than what we’ve thrown at it here. The same is true for the FakeItEasy component. Both of these components are well used, well maintained open source projects. You can find lots of documentation and examples for both. Or you can use any number of other DI containers and mocking frameworks to achieve equivalent results.

The source code for the example is available here, and the blog entry the precedes this one is available here.


Practical Dependency Injection 101

May 27, 2011

In this post we take a look at dependency injection (DI). Target audience is competent .NET developers, C# specifically (but VB’ers who read C# can benefit just as much), who’ve heard of DI but haven’t gotten around to figuring out how it fits in their day to day.
What is Dependency Injection
The first question that we [...]

Read the full article →

NuGet – Galleries of Geeky Goodness.

January 12, 2011

In a previous post I described how Scott Hanselman’s presentation during PDC 2010 introduced me to several wonderful and interesting technologies that are either just now out or about to be. The first one I’ll discuss is NuGet. There are many excellent introductions to NuGet by Hanselman and others. I’ll see if I can make [...]

Read the full article →

Open Source, MVC, MVVM, Entity Framework, NuGet, and More…

January 12, 2011

Updated: see the NuGet post
The 2010 PDC was a few months ago. There was plenty of interesting and exciting tech news coming from the conference, but the one session that really sparked something with me was Scott Hanselman’s Presentation, ASP.NET + Packaging + Open Source = Crazy Delicious. Officially, I was mining PDC for Azure [...]

Read the full article →

5Dm2 vs S95 Holiday Shootout Deathmatch!

December 4, 2010

Hey that’s an enthusiastic title…
My wife and son (and what the heck, me too) were surprised to see snow falling this morning as we lazed around the fire in the den. Not just some wispy dots, but some decent sized flakes. Not very common in Greensboro, NC the first week of December. There are many [...]

Read the full article →

In Car Video–Carolina Motorsports Park

August 22, 2010

I’ve just finished uploading a new in-car video from the Hurricane region PCA Driver’s Ed event at Carolina Motorsports Park in South Carolina. View it embedded here, or click the link below the picture to go to Vimeo.

PCA DE CMP August 2010 from Eric Vincent on Vimeo.
Some notes about the video and data acquisition, [...]

Read the full article →

Combinators in C#

May 3, 2010

As C# has evolved it has acquired more and more of what some people refer to has functional programming features and constructs. One such concept is the idea that a function is a "first class” value. This is a fancy way of saying that functions are values that can be passed to and returned from [...]

Read the full article →

Parsing Json using F#

April 27, 2010

I was in one of those curious moods the other day, and decided to check out the API for the service behind my RSS reader, FeedDemon. I like this reader because it keeps my subscriptions and read / unread data synchronized across machines and my iPhone via an app called NetNewsWire.
Well it ends up that [...]

Read the full article →

Roll Your Own Language Constructs

February 3, 2010

My last couple of blog entries were ostensibly about lambda functions (last one, one before). With these ideas, or a general comfort level with lambdas and the Action<> and Func<> delegate types in the back of your mind, consider this.
I was working on a project where the development team was instructed to implement a retry [...]

Read the full article →