Verifiying I understand the difference between IoC, Ioc Container, DI and the service locator

Question

read a lot of posts about the difference between 3 idioms. But became more confused, then I came across this article: http://martinfowler.com/articles/injection.html

I just want to see if I got it right. Please correct me if I am wrong. Please let me know about corrections and additions:

IoC - concept decoupling the application from the implementation of the service it uses. The application contains a link to Iservice and is not responsible for the provision of a specific service.

There are at least two ways to achieve this goal:

• DI A specific service is introduced as ctor param / throws an injection of the setter / throw interface ( what does the last value mean? )

• ServiceLocator is a component that knows all the specific services that an application may need. The application explicitly requests a specific service from the locator.

* The IoC container is the actual factory control ("provider").

I was a little embarrassed by the fact that “when to prefer (1) or (2)” is part of the article. can someone tell from their own experience in the words of a layman?

“A service locator has a slight advantage because of its simpler behavior. However, if you create classes that will be used in several applications, then the more efficient option is“ Dependency Injection. ”→ How is the locator simpler? Because it explicitly uses a method call ? What is the best use of DI if you have multiple applications?

Answer 1

IoC is the concept of decoupling an application from the implementation of the service it uses.

It’s true that IoC goes hand in hand with implementation decoupling interfaces, but I consider this a more general principle. This SO answer gives a very good explanation of the concept.

There are at least two ways to achieve this:
1) DI
2) ServiceLocator

I would not say that the Service Locator pattern is an example of a control inverse. Quite the contrary - when you use the Service Locator, you acquire the necessary dependencies in an active way, no one does it for you (contrary to the DI, where the container handles the dependencies for you, you just need to give it the opportunity to do it - a setter, constructor parameter or implementing an interface method injection).

How is the locator simpler? because it explicitly uses a method call?

I think Martin Fowler refers to the general idea of ​​IoC, which can make the code more difficult to understand if you have never seen the IoC / DI concept used earlier. On the other hand, using Service Locator code to get some dependencies may be easier to understand at the first meeting.

What is the best way to use DI with multiple applications?

When you create a component that needs to be reused, the advantage of DI is that it does not make your component dependent on anything other than the original dependency (in the MF example, MovieLister depends only on the MovieFinder interface when using DI). In addition, it’s quite easy for other users to use your component - you just need to pass the dependencies using the DI tools you provided.

When using Service Locator, you also add a dependency on the interface of the service locator itself. With an isolated interface for the locator, this may not be a problem. But it can also be more difficult for users of your component to satisfy the dependencies of your component, as MF writes:

The difference arises if the lister is a component that I provide to the application that other people write. In this case, I know little about the service locator APIs that my clients will use. Each customer can have their own incompatible service locators.