【转】Understanding Inversion of Control, Dependency Injection and Service Locator Print

原文：https://www.dotnettricks.com/learn/dependencyinjection/understanding-inversion-of-control-dependency-injection-and-service-locator

-----------------------------------------------------------------------------------------

Understanding Inversion of Control, Dependency Injection and Service Locator

Print

   Author : Shailendra Chauhan

 Posted On : 10 Apr 2013

 Total Views : 133,973   

 Updated On : 26 Sep 2016

 

So many developers are confused about the the term Dependency Injection (DI). The confusion is about terminology, purpose, and mechanics. Should it be called Dependency Injection, Inversion of Control, or Service Locator? Over the Internet, there are a lot of articles, presentations and discussion but, unfortunately, many of them use conflicting terminology. In this article I would like to explain, all these three OOPS concepts.

Dependency Inversion Principle (DIP)

The Dependency Inversion Principle states that:

1. High level modules should not depend upon low level modules. Both should depend upon abstractions.

2. Abstractions should not depend upon details. Details should depend upon abstractions.

The Dependency Inversion principle (DIP) helps us to develop loosely couple code by ensuring that high-level modules depend on abstractions rather than concrete implementations of lower-level modules. The Inversion of Control pattern is an implementation of this principle

Inversion of Control (IoC)

The term Inversion of Control (IoC) refers to a programming style where a framework or runtime, controls the program flow. Inversion of control means we are changing the control from normal way. It works on Dependency Inversion Principle. The most software developed on the .NET Framework uses IoC.

For example

1. When you write an ASP.NET application, you lie into the ASP.NET page life cycle, but you aren’t in control while ASP.NET is.

2. When you write a WCF service, you implement interfaces decorated with attributes. You may be writing the service code, but ultimately, you aren’t in control while WCF is.

More over IoC is a generic term and it is not limited to DI. Actually, DI and Service Locator patterns are specialized versions of the IoC pattern or you can say DI and Service Locator are the ways of implementing IoC.

For example, Suppose your Client class needs to use a Service class component, then the best you can do is to make your Client class aware of an IService interface rather than a Service class. In this way, you can change the implementation of the Service class at any time (and for how many times you want) without breaking the host code.

IoC and DIP

DIP says High level module should not depend on low level module and both should depend on abstraction. IoC is a way that provide abstraction. A way to change the control. IoC gives some ways to implement DIP. If you want to make independent higher level module from the lower level module then you have to invert the control so that low level module not controlling interface and creation of the object. Finally IoC gives some way to invert the control.

IoC and DI

The terms Dependency Injection (DI) & Inversion of Control (IoC) are generally used interchangeably to describe the same design pattern. The pattern was originally called IoC, but Martin Fowler proposed the shift to DI because all frameworks invert control in some way and he wanted to be more specific about which aspect of control was being inverted.

Dependency Injection (DI)

DI is a software design pattern that allow us to develop loosely coupled code. DI is a great way to reduce tight coupling between software components. DI also enables us to better manage future changes and other complexity in our software. The purpose of DI is to make code maintainable.

The Dependency Injection pattern uses a builder object to initialize objects and provide the required dependencies to the object means it allows you to "inject" a dependency from outside the class.

Service Locator (SL)

Service Locator is a software design pattern that also allow us to develop loosely coupled code. It implements the DIP principle and easier to use with an existing codebase as it makes the overall design looser without forcing changes to the public interface.

The Service Locator pattern introduces a locator object that objects is used to resolve dependencies means it allows you to "resolve" a dependency within a class.

Dependency Injection and Service Locator with Example

Let's consider the simple dependency between two classes as shown in the fig and it is a simple approach, that you know.

Now have a look at the folllowing code:

1. public class Service
2. {
3. public void Serve()
4. {
5. Console.WriteLine("Service Called");
6. //To Do: Some Stuff
7. }
8. }
9. public class Client
10. {
11. private Service _service;
12. public Client()
13. {
14. this._service = new Service();
15. }
16. public void Start()
17. {
18. Console.WriteLine("Service Started");
19. this._service.Serve();
20. //To Do: Some Stuff
21. }
22. }

Clearly, the Client class has a dependency on the Service class. If you want to make it loosely coupled, you have to use IoC to make the more flexible and reusable it.

To implement the IoC, you have the choice of two main patterns: Service Locator and Dependency Injection. The Service Locator allows you to "resolve" a dependency within a class and the Dependency Injection allows you to "inject" a dependency from outside the class.

Using Service Locator

The above code can be re-written as by using Service Locator as follows.

1. public interface IService
2. {
3. void Serve();
4. }
5. public class Service : IService
6. {
7. public void Serve()
8. {
9. Console.WriteLine("Service Called");
10. //To Do: Some Stuff
11. }
12. }
13. public static class LocateService
14. {
15. public static IService _Service { get; set; }
16. public static IService GetService()
17. {
18. if (_Service == null)
19. _Service = new Service();
20. return _Service;
21. }
22. }
23. public class Client
24. {
25. private IService _service;
26. public Client()
27. {
28. this._service = LocateService.GetService();
29. }
30. public void Start()
31. {
32. Console.WriteLine("Service Started");
33. this._service.Serve();
34. //To Do: Some Stuff
35. }
36. }

Sample ServiceLocator-Implementation:

1. class Program
2. {
3. static void Main(string[] args)
4. {
5. var client = new Client();
6. client.Start();
7. Console.ReadKey();
8. }
9. }

The Inversion happens in the constructor, by locating the Service that implements the IService-Interface. The dependencies are assembled by a "Locator".

Using Dependency Injection

The above code can also be re-written as by using Dependency Injection as follows.

1. public interface IService
2. {
3. void Serve();
4. }
5. public class Service : IService
6. {
7. public void Serve()
8. {
9. Console.WriteLine("Service Called");
10. //To Do: Some Stuff
11. }
12. }
13. public class Client
14. {
15. private IService _service;
16. public Client(IService service)
17. {
18. this._service = service;
19. }
20. public void Start()
21. {
22. Console.WriteLine("Service Started");
23. this._service.Serve();
24. //To Do: Some Stuff
25. }
26. }

Sample Builder-Implementation:

1. class Program
2. {
3. static void Main(string[] args)
4. {
5. client = new Client(new Service());
6. client.Start();
7. Console.ReadKey();
8. }
9. }

The Injection happens in the constructor, by passing the Service that implements the IService-Interface. The dependencies are assembled by a "Builder" and Builder responsibilities are as follows:

1. knowing the types of each IService

2. according to the request, feed the abstract IService to the Client

What's wrong with the above two approaches?

Above two approaches can be resemble to DI FACTORY. There are some issues with the above two approaches:

1. It is hardcoded and can't be reused across applications, due to hardcoded factories. This makes the code stringent to particular implementations.

2. It is Interface dependent since interfaces are used for decoupling the implementation and the object creation procedure.

3. It's Instantiating instantiations are very much custom to a particular implementation.

4. Everything is compile time since all the dependent types for the objects in the instantiation process (factory) have to be known at compile time.

What is the Solution ?

IoC containers is the solution to resolve above two approaches issues. Hence, when we compose applications without a DI CONTAINER, it is like a POOR MAN’S DI. Moreover, DI CONTAINER is a useful, but optional tool.

You can also improve above two approaches by doing some more work. You can also combine above two approaches to make code more independent

Dependency Injection VS Service Locator

1. When you use a service locator, every class will have a dependency on your service locator. This is not the case with dependency injection. The dependency injector will typically be called only once at startup, to inject dependencies into the main class.

2. The Service Locator pattern is easier to use in an existing codebase as it makes the overall design looser without forcing changes to the public interface. Code that is based on the Service Locator pattern is less readable than the equivalent code that is based on Dependency Injection.

References

http://www.objectmentor.com/resources/articles/dip.pdf

http://satoricode.net/2011/10/01/UnderstandingTheBenefitsOfADependencyInjectionContainerIOC.aspx

What do you think?

I hope you will enjoy the DIP, IoC, DI and SL patterns. I would like to have feedback from my blog readers. Your valuable feedback, question, or comments about this article are always welcome.