How We Do Dependency Injection

Dependency Injection (DI) design pattern has become more and more popular in software development recent years. There are many open source frameworks that help us apply DI design pattern out there, like Castle Windsor, NInject, StructureMap, Unity,… just named a few. From my point of view, using a framework for DI means using an Inversion of Control (IoC) container to wire up the dependencies between objects and let it manages their life cycles after registering the object graphs with that container.


Almost softwares I built in recent 2-3 years have been applied DI design pattern with a help of an IoC container. For what? you may ask. Well, I think the benefit of applying DI is that it allows me to design loosely coupled objects to ease unit testing. At run time, the IoC container helps wire up all the dependencies between objects for me.

However, using an IoC container for DI in building softwares doesn’t mean I always use it in a right way. In other words, there was a bad practice applied when using an IoC container. One of the wrong way I can tell you is making an IoC container static or singleton and use it in many places, across layers which is supposed to be a Service Locator (anti-)pattern. If you want to be clear, read this: http://www.devtrends.co.uk/blog/how-not-to-do-dependency-injection-the-static-or-singleton-container, or even if you want to be more serious on the topic, read this article and the comments too: http://blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx

After reading those two articles and agreed with the authors, I realized that I have used the static IoC container in many softwares I built. So I decided to re-factored our code to avoid doing that wrong thing again. The IoC container that I am familiar with is Castle Windsor. I used it from the time I knew what DI is, and I am still using it just because I like the way to register types with IWindsorContainer using fluent interfaces that is very readable.

To demonstrate, here is an ASP.NET MVC application that used the Service Locator to resolve the services on which a controller depends.

The static IoC container class:

public static class IoC
{
    public static IWindsorContainer Container { get; set; }
}

The IoC.Container static property will be assigned to an instance of WindsorContainer class in the global MvcApplication (Global.ascx.cs) and it as well will be used to register types at web application start up:

public class MvcApplication : System.Web.HttpApplication
{
    static MvcApplication()
    {
        IoC.Container = new WindsorContainer();
        RegisterComponentsWith(IoC.Container);
    }

    private static void RegisterComponentsWith(IWindsorContainer container)
    {
        container.Register(Component.For<IRepository>().ImplementedBy<Repository>().LifeStyle.Transient);
        container.Register(Component.For<IAccountService>().ImplementedBy<AccountService>().LifeStyle.Transient);
        container.Register(Component.For<IEmailService>().ImplementedBy<EmailService>().LifeStyle.Transient);
container.Register(Component.For<IFormsAuthenticationService>().ImplementedBy<FormsAuthenticationService>().LifeStyle.Transient);
        // other type registrations...
    }
}

And this is how we use that IoC container to resolve service types in a controller:

public class AccountController : Controller
{
    public T GetService<T>()
    {
        return IoC.Container.Resolve<T>();
    }

    public AccountController()
    {
    }
    public ActionResult LogOn(LogOnModel model)
    {
        if (ModelState.IsValid)
        {
            IAccountService accountService = GetService<IAccountService>();
            if (accountService.ValidateLogin(model.Email, model.Password))
            {
                // code...
            }
            // rest of the code...
        }
        // rest of the code...
    }
    // rest of the code
}

Now I am using an IoC container badly and _without_ dependency injection. So how to apply DI correctly, you ask? The solution is to get rid of static IoC container and remove the dependency to that container from not only the controller(s) but also anywhere on the code, except the code that instantiates the container and registers the object graphs in the global MvcApplication.

Here is the refactored AccountController that applies DI correctly

public class AccountController : Controller
{
    private readonly IAccountService _accountService;
    private readonly IEmailService _emailService;
    private readonly IFormsAuthenticationService _formsAuthenticationService;

    public AccountController(IAccountService accountService,
        IEmailService emailService,
        IFormsAuthenticationService formsAuthenticationService)
    {
        _accountService = accountService;
        _emailService = emailService;
        _formsAuthenticationService = _formsAuthenticationService;
    }
    public ActionResult LogOn(LogOnModel model)
    {
        if (ModelState.IsValid)
        {
            if (_accountService.ValidateLogin(model.Email, model.Password))
            {
                // code...
            }
            // rest of the code...
        }
        // rest of the code...
    }
    // rest of the code
}

We also need to implement a custom controller factory that is responsible for creating an appropriate controller and also injecting the services on which that controller depends. Here is the custom controller factory which inherits from ASP.NET MVC’s DefaultControllerFactory class:

public class WindsorControllerFactory : DefaultControllerFactory
{
    private readonly IWindsorContainer _container;

    public WindsorControllerFactory(IWindsorContainer container)
    {
        _container = container;
    }

    protected override IController GetControllerInstance(System.Web.Routing.RequestContext requestContext, Type controllerType)
    {
        if (controllerType == null)
            throw new HttpException(404, string.Format("The controller for path '{0}' could not be found or it does not implement IController.",
                requestContext.HttpContext.Request.Path));

        return (IController)_container.Resolve(controllerType);
    }

    public override void ReleaseController(IController controller)
    {
        _container.Release(controller);
    }
}}

Here is the revised code to instantiate the container and register types with it in MvcApplication class:

public class MvcApplication : System.Web.HttpApplication
{
    private static IWindsorContainer _container = new WindsorContainer();
    static MvcApplication()
    {
        RegisterComponentsWith(_container);
    }

    protected void Application_Start()
    {
        AreaRegistration.RegisterAllAreas();

        RegisterGlobalFilters(GlobalFilters.Filters);
        RegisterRoutes(RouteTable.Routes);
        ControllerBuilder.Current.SetControllerFactory(new WindsorControllerFactory(_container));
    }

    private static void RegisterComponentsWith(IWindsorContainer container)
    {
        container.Register(Component.For<IRepository>().ImplementedBy<Repository>().LifeStyle.Transient);
        container.Register(Component.For<IAccountService>().ImplementedBy<AccountService>().LifeStyle.Transient);
        container.Register(Component.For<IEmailService>().ImplementedBy<EmailService>().LifeStyle.Transient);
        container.Register(Component.For<IFormsAuthenticationService>().ImplementedBy<FormsAuthenticationService>().LifeStyle.Transient);

        // register controllers with the container
        container.Register(
                AllTypes.FromThisAssembly()
                .BasedOn<IController>()
                .Configure(c => c.LifeStyle.Transient));
        // other type registrations...
    }

    // code...
}

Now I am using DI correctly. But there still is a problem to me: since I want to use dependency injection, I have to list out all the dependencies to services in controller constructor, here I use constructor injection or I may opt to use property injection. Both ways leads me to have a ‘greedy’ controller because there are controller’s action methods being invoked  that do not actually use any of dependent services at all!

After a while looking for a way to solve the problem, I found that Castle Windsor has a feature called TypedFactoryFacility that allows us to define an interface as a factory which, once registered with the container, will resolves the types for us on behalf of container. Note that we don’t need to provide any implementation for that typed service factory interface at all.

Here is the typed factory interface to resolve the service(s):

public interface IServiceFactory
{
    T Create<T>();

    void Release(object service);
}

Register the typed factory with the container:

// code..
container.Register(Component.For<IRepository>().ImplementedBy<Repository>().LifeStyle.Transient);
container.Register(Component.For<IAccountService>().ImplementedBy<AccountService>().LifeStyle.Transient);
container.Register(Component.For<IEmailService>().ImplementedBy<EmailService>().LifeStyle.Transient);
container.Register(Component.For<IFormsAuthenticationService>().ImplementedBy<FormsAuthenticationService>().LifeStyle.Transient);
// code..
container.AddFacility<TypedFactoryFacility>();
container.Register(
    Component.For<IServiceFactory>()
        .AsFactory()
        .LifeStyle.Transient);
// code..

Use the typed factory in the controller to resolve the designed service once we really need it:

public class AccountController : ControllerBase
{
    private readonly IServiceFactory _serviceFactory;
    public AccountController(IServiceFactory serviceFactory)
    {
        _serviceFactory = serviceFactory;
    }

    [HttpPost]
    public ActionResult LogOn(LogOnModel model)
    {
        if (ModelState.IsValid)
        {
            IAccountService accountService = _serviceFactory.Create<IAccountService>();
            if (accountService.ValidateLogin(model.Email, model.Password))
            {
                IFormsAuthenticationService formsAuthenticationService = _serviceFactory.Create<IForsAuthenticationService>();
                formsAuthenticationService.SignIn(model.Email, model.RememberMe);
                _serviceFactory.Release(formsAuthenticationService);
                // rest of code...
            }
            _serviceFactory.Release(accountService);
            // rest of code...
        }
        // rest of code...
    }
    // rest of code
}

From the code, every when you call:

IAccountService accountService = _serviceFactory.Create<IAccountService>();

…is  equivalent of calling:

IAccountService accountService = kernel.Resolve<IAccountService>();

That’s it. I hope you understand how  to apply DI correctly and also find the usefulness of Castle Windsor’s TypedFactoryFacility.

Comments are welcome.

Posted on August 19, 2011, in dependency injection and tagged , , . Bookmark the permalink. 11 Comments.

  1. Service factory is fine but i don’t like this line:

    _serviceFactory.Release(formsAuthenticationService);

    Should we let the IOC handle the life of object?

    • I think you don’t need to explicitly call the Release method on the service factory, if the service factory’s life style is Transient, then once it is released, the services are released to. Here is the exerpted from the Castle Windsor wiki – http://docs.castleproject.org/Windsor.Typed-Factory-Facility-interface-based-factories.ashx

      “Releasing the factory releases all component: Typed factory (both interface and delegate-based) owns the components you resolve through it. That means that when you release the factory, all the components you resolved from the factory will be released as well.”

  2. When do dependency injection for the code. I am going to avoid using all components from DI framework (kernel, windsor container,…) in all layers (UI, Service, Business, Data access). So that mean I will try to wrapping all of them to one layer and use this layer for others. That’s exactly you did in this post.
    One more thing, I read and found out one line of code was very abnormal.
    container.Register(Component.For().ImplementedBy().LifeStyle.Transient);
    Maybe we should use like this
    container.Register(Component.For().ImplementedBy().LifeStyle.Transient);
    This is your mistake when typing your post, isn’t it?
    But anyway, this post is very good, a.Huy. It pointed out all best practices when we do dependency injection. Cheers!

    • Sorry. Maybe, WordPress tripped all my typing:
      container.Register(Component.For(IAccountService)().ImplementedBy(IAccountService)().LifeStyle.Transient);
      should be
      container.Register(Component.For(IAccountService)().ImplementedBy(AccountService)().LifeStyle.Transient);

    • Good caught. Thang. That line should be container.Register(Component.For[IAccountService]().ImplementedBy[AccountService]().LifeStyle.Transient);

  3. Thanks for the articles.

    I’m fairly new to this but doesn’t the revised DI method you use suffer from some of the issues with the Service Locator anti-pattern. For some external user making use of the controller, it isn’t clear what dependencies the controller has. Maybe not an issue in MVC and it’s better than a static container since it has the IServiceFactory constructor parameter which makes it clear that something needs to be set up at least.

    I wonder if something like Resharper has/will pick up on these sort of DI issues and issue warnings if things haven’t been registered with the container that should have been.

    • Agree with @mungojam: “It isn’t clear what dependencies the controller has”.

      “But there still is a problem to me: since I want to use dependency injection, I have to list out all the dependencies to services in controller constructor, here I use constructor injection or I may opt to use property injection”

      Regarding to the problem above, I think it’s the sign showing us the controller need to be on diet and it’s time to split responsibilities and make thinner controllers.

      • I understand your opinion. However, in the context of web application using ASP.NET MVC, I really don’t like injecting to much dependencies to a controller that I might not use them at all, to me it is just a waste of resources, so it is just my preference to do DI in web context. In other type of application, like WPF, I usually list all the dependencies and let the container resolves them for me because a, e.g. a ViewModel lives longer (stateful) and it can use all objects that it depends on.

  4. I see ways to improve your “EF series” from the point of view of this article!

  5. Good work. Very clear summing up your experiences with DI. Helped newbies like me to go on the right path. Not many people give out full useful examples like this. Most people just say “Your code needs improve, your way is wrong…etc” in abstract opinions making themselves feel professional, but without spitting out anything useful as feedback. So, yeah, this is the sh@#$%t ! Good article & Thanks it helps!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: