In Symfony2, why is it a bad idea to inject the service container, rather than individual services?

My list of reasons why you should prefer injecting services:

1. Your class is dependent only on the services it needs, not the service container. This means the service can be used in an environment which is not using the Symfony service container. For example, you can turn your service into a library that can be used in Laravel, Phalcon, etc - your class has no idea how the dependencies are being injected.

2. By defining dependencies at the configuration level, you can use the configuration dumper to know which services are using which other services. For example, by injecting @mailer, then it's quite easy to work out from the service container where the mailer has been injected. On the other hand, if you do $container->get('mailer'), then pretty much the only way to find out where the mailer is being used is to do a find.

3. You'll be notified about missing dependencies when the container is compiled, instead of at runtime. For example, imagine you have defined a service, which you are injecting into a listener. A few months later, you accidentally delete the service configuration. If you are injecting the service, you'll be notified as soon as you clear the cache. If you inject the service container, you'll only discover the error when the listener fails because of the container cannot get the service. Sure, you could pick this up if you have thorough integration testing, but ... you have got thorough integration testing, haven't you? ;)

4. You'll know sooner if you are injecting the wrong service. For example, if you have:

   public function __construct(MyService $my_service)
   {
      $this->my_service = $my_service;
   }
   

   But you've defined the listener as:

   my_listener:
       class: Whatever
       arguments: [@my_other_service]
   

   When the listener receives MyOtherService, then PHP will throw an error, telling you that it's receiving the wrong class. If you're doing $container->get('my_service') you are assuming that the container is returning the right class, and it can take a long time to figure out that its' not.

5. If you're using an IDE, then type hinting adds a whole load of extra help. If you're using $service = $container->get('service'); then your IDE has no idea what $service is. If you inject with

   public function __construct(MyService $my_service)
   {
      $this->my_service = $my_service;
   }
   

   then your IDE knows that $this->my_service is an instance of MyService, and can offer help with method names, parameters, documentation, etc.

6. Your code is easier to read. All your dependencies are defined right there at the top of the class. If they are scattered throughout the class with $container->get('service') then it can be a lot harder to figure out.

7. Your code is easier to unit test. If you're injecting the service container, you've got to mock the service container, and configure the mock to return mocks of the relevant services. By injecting the services directly, you just mock the services and inject them - you skip a whole layer of complication.

8. Don't be fooled by the "it allows lazy loading" fallacy. You can configure lazy loading at configuration level, just by marking the service as lazy: true.

Personally, the only time injecting the service container was the best possible solution was when I was trying to inject the security context into a doctrine listener. This was throwing a circular reference exception, because the users were stored in the database. The result was that doctrine and the security context were dependent on each other at compile time. By injecting the service container, I was able to get round the circular dependency. However, this can be a code smell, and there are ways round it (for example, by using the event dispatcher), but I admit the added complication can outweigh the benefits.

Besides all disadvantages explained by others (no control over used services, run time compilation, missing dependencies, etc.)

There is one main reason, which breaks the main advantage of using DIC - Dependencies replacement.

If service is defined in library, you wont be able to replace it dependencies with local ones filling your needs.

Only this reason is strong enough, to not inject whole DIC. You just break whole idea of replacing dependencies since they are HARDCODED! in service;)

BTW. Don't forget to require interfaces in service constructor instead of specific classes as much as you can - again nice dependencies replacement.

EDIT: Dependencies replacement example

Service definition in some vendor:

<service id='vendor_service' class="My\VendorBundle\SomeClass" />
    <argument type="service" id="vendor_dependency" />
</service>

Replacement in your app:

<service id='vendor_service' class="My\VendorBundle\SomeClass" />
     <argument type="service" id="app_dependency" />
</service>

This allows you to replace vendor logic with your customized one, but don't forget to implement required class interface. With hardcoded dependencies you're not able to replace dependency in one place.

You can also override vendor_dependency service, but this will replace it in all places not only in vendor_service.