theory: “Service Locator” “IOC Container” “IOC” “DI”

Question

can you help me with theory of some patterns. I have tried to describe them, I have tried my best, but I think my statements are wrong, so help )).

1) "DI" and "IOC" - the same.

2) "IOC Container" - it is an instance of an object that can resolve dependences like:

void Test()
{
    // create IOC Container to resolve
    // dependences for SomeMethod method
    var container = new SomeContainer();
    container.For(typeof(IEmaleSender), typeof(SuperEmaleSender));

    // Pass IOC Container to resolve dependences in SomeMethod
    SomeMethod(container);
}

void SomeMethod(SomeContainer container)
{
    IEmaleSender emailSender = container.Resolve(IEmaleSender);
    emailSender.SendEmail();
}

3) "Service Locator" - It is something like static object that contains Dictionary<Type, object> where value is an instance of key type. And this static object have 2 methods: Add and Get . So I can add object on start of my application and request it from everywhere:

void Test()
{
    // Assign instanse of SuperEmaleSender to Locator
    SuperEmaleSender emailSender = new SuperEmaleSender()
    SomeLocator.Add(typeof(SuperEmaleSender), emailSender);

    SomeMethod();
}

void SomeMethod()
{
    SuperEmaleSender emailSender = SomeLocator.Get(typeof(SuperEmaleSender));
    emailSender.SendEmail();
}

4) It is a good practice to combine "Service Locator" and "IOC Container". So you can instantiate "IOC Container" on application start and request it through "Service Locator" from everywhere.

5) In ASP MVC5, "Service Locator" already included. I'm talking about DependencyResolver .

Thank you for your help.

Answer 1

As for the combining service locator with IoC - when you have proper IoC container, you really shouldn't use service locator (or perhaps in most cases you should not use it at all), because the whole point of IoC and DI is to pass dependencies from outside of class and specify explicitely what dependecies this class has. Using service locator inside would hide the dependency. Service locator is by some people considered an anti-pattern .

Answer 2

Service Locator is ALMOST an extremely primitive Dependency Injection. It generally only lets you return singleton instances. Its not really DI because you have to get instances by hand and new up objects by hand rather then let the DI engine do it for you (new up object and inject the service references into them). DI also gives you more control over the lifetime of the objects.

Answer 3

DI stands for Depency Injection and IoC for Inversion of Control. Imagine you have a class that access the database. The responsability of that class is to insert an item, but you need a database connection to do so. If the responsability of the class is only to insert an item, it won't know how to start that connection, only how to use it. Thinking of it, you'll set the connection as a dependency of that class, passing the responsability of creating that connection to anyone that want to use it. You are inverting the control using dependency injection, passing the responsability to anyone that knows how a connection works.

You can use an IoC container to help you manage the dependencies between your classes.

You can see this question for a more detailed answer: Inversion of Control vs Dependency Injection