IoC vs Dependency Injection (DI) vs. Service Locator (SL)

IoC vs DI (Dependency Injection)? IoC is the general concept where control of flow is *Inverted* from client code to framework, which “Does something for the client”. SL (Service Locator) and DI (Dependency Injection) are two design patterns stem off from IoC.
1. In case of DI (Dependency Injection), the application framework returns to client pre-configured dependencies. Dependencies are configured by way of Constructor|Setter|Method “Injection” – Injection is just a big word for simply “Setting member variables” via Constructor|Setter|Method.
In Spring.NET, dependency config are stored in xml config file, further reduces what “client” need to know about the dependencies in order to use them.

2. In case of SL (Service Locator), the application framework, containing all services instances, returns relevant Service instance by looking up a map, with a *key* specified by client. Service Locator which is basically a map.
Example, 3 of 10 dependencies, which your team develop, we use Spring.NET. 7 of 10 use Unity – developed by another application team. SL look up the type of dependency client requests, and instantiate+configure the requested dependency using either Spring.NET, or Unify, depending on mapping. (See example below)


Here’s one example to show difference between Service Locator, and Dependency Injection:

public interface IIoCService
Object GetProxy(Type T, string Name);

public class UnityIoC
IUnityContainer UnityCtx = new UnityContainer();

public UnityIoC()
… type registrations …

public Object GetProxy(Type T, string Name)
return UnityCtx.Resolve(T, Name); // Unity we get proxy via “Resolve” method, unlike Spring, takes argument Type T

public class SpringIoC : IIoCService
private IApplicationContext SpringCtx = ContextRegistry.GetContext();

public Object GetProxy(Type T, string Name)
return SpringCtx.GetObject(Name); // DI: Spring get proxy via “GetObject” – Spring Framework instantiate + pre-configure proxy in accordance to specification from app|web.config

public class IoCServiceLocator
private IDictionary<Type, IIocService> map = …

public static Object GetProxy(Type type)
IIoCService Service = map[type];
return Service.GetProxy(type, type.Name);

From client code,
ISomeImpl1 Proxy1 = (ISomeImpl1) IoCServiceLocator.GetProxy(typeof(Depend_1));
ISomeImpl4 Proxy4 = (ISomeImpl4) IoCServiceLocator.GetProxy(typeof(Depend_4));

In this example,

(a) Instantiation and Configuration of Proxy1 and Proxy4 are done via DI (Dependency Inject) with Spring.NET and Unity respectively.
(b) IoCServiceLocator implements Service Locator patterns which locates *mapped* IoC container based on type client is requesting.

Hope this clears some of the confusion around the subject IoC vs DI vs SL.


Java Road Tripping

Again, while reading through the Spring documentation, I came across this article of Martin Fowler.
I’ll try to give a summary of his article and my opinions about it.


Every professional software engineer should know what dependency injection or inversion of control is about, but i’ll try to explain it for those who don’t.
I’ll use quite the same examples as Martin did in his article, which I’ll try to update a little. You can find a link to the source code at the bottom of this blog post (Maven is required to build the source).

Imagine you have to display a list of movies directed by a specified director.
I have an interface and a concrete implementation for finding movies.

To list the movies with a specified director, the following code is used:

Especially the MovieFinder at line 02 is of importance here.
You need to have a…

View original post 2,214 more words

Leave a Reply

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

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

Google photo

You are commenting using your Google 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 )

Connecting to %s