Global variable vs DI Container.

Question

Can someone describe pros and cons of both methods, and when you prefer one over another?

interface IService
{
    object GetSomething();
}

class Service:IService{...}

DI

Container.Register<IService, Service>();

class A
{
    public A(IService service)
    {
        _service = service;
    }
}

Global

class Config
{
    public static IService Service {get;set;}
}

Config.Service = new Service();

class A
{
    public A()
    {
        _service = Config.Service;
    }
}

Answer 1

Your 'Global' approach is more or less a Poor Man's Service Locator. Many people, including me, consider Service Locator an anti-pattern.

The main reason for that is that its usage is implicit; it is hidden from the consumer, so a developer writing client code will probably not be aware that it exists.

As a client developer, I could easily write this code:

var a = new A();

and then just start partying on a straight away. If A depends on IService, methods invoked on the instance are likely to throw exceptions if Config.Service was never set, and there is no guarantee that this ever happened.

On the other hand, when you use Constructor Injection, you can more or less guarantee that the IService instance is being injected. Now this code will not compile:

var a = new A();

so it forces client developers to supply an instance of IService. Obviously client developers could simply supply null:

var a = new A(null);

but you could easily fix this with a Guard Clause.

class A
{
    public A(IService service)
    {
        if(service == null)
        {
            throw new ArgumentNullException();
        }

        _service = service;
    }
}

This guarantees that the service instance is valid, particularly if you combine it by making the _service field readonly.

Whether or not you use a DI Container to resolve dependencies is a perpendicular matter.

There are, in my opinion, no advantages of using a Service Locator over Constructor Injection.

Answer 2

The Global one is a service locator. Martin Fowler compares and contrasts the two patterns far better than I ever could in his article Inversion of Control Containers and the Dependency Injection pattern.

Personally I'd go with DI.

Answer 3

Using a DI Container

• -ve Learning curve to begining to use one
• -ve Might be overkill depending on the size of your project
• +ve Usually means writing less boilerplate code
• +ve Often have mechanisms in place to handle object life span for you (singleton, caching strategies etc)

In your global scenario:

• -ve When looking at the constructor through intellisense the immediate dependencies it has are unknown. Don't forget, each one of the classes it depends on will probably have dependencies of their own.
• -ve Harder to setup during test, are you sure you've setup all the necessary objects in the Config ?
• +ve Simpler to get started with