In Symfony2, warum ist es eine schlechte Idee ist, injizieren Sie die service-container, sondern als einzelne Dienstleistungen an?

Meine Liste von Gründen, warum sollten Sie lieber die Injektion Dienstleistungen:

1. Ihre Klasse ist nur abhängig von den Dienstleistungen, die es braucht, nicht die service-container. Dies bedeutet, dass der Dienst verwendet werden kann, in einer Umwelt, die nicht mit dem Symfony-service-container. Zum Beispiel, können Sie Ihren service in eine Bibliothek, die verwendet werden können, in Laravel, Phalcon, usw - deine Klasse hat keine Ahnung, wie die Abhängigkeiten injiziert werden.

2. Durch die Definition von Abhängigkeiten in der konfigurationsebene, können Sie die Konfiguration dumper zu wissen, welche Dienste welche anderen Dienste. Zum Beispiel durch die Injektion @mailer ist, dann ist es ganz leicht zu work out aus dem service-container, in dem die mailer gespritzt wurden. Auf der anderen Seite, wenn Sie $container->get('mailer'), dann ist so ziemlich der einzige Weg, um herauszufinden, wo der mailer verwendet wird, ist eine find.

3. Erhalten Sie eine Benachrichtigung über fehlende Abhängigkeiten, wenn die container kompiliert wird, anstatt zur Laufzeit. Zum Beispiel, stellen Sie sich vor Sie definiert haben, einen Dienst, in dem Sie die Injektion in einen listener. Ein paar Monate später, Sie versehentlich löschen Sie die service-Konfiguration. Wenn Sie die Injektion der service, werden Sie benachrichtigt, sobald Sie den cache löschen. Wenn Sie Spritzen den service-container, werden Sie entdecken nur Fehler, wenn der Hörer schlägt fehl, weil der container nicht den service. Sicher, man könnte das abholen, wenn Sie umfassende integration testen, aber ... Sie haben Gründliche integration testen, haben Sie nicht? 😉

4. Wissen Sie früher, wenn Sie die Injektion der falsche service. Zum Beispiel, wenn Sie haben:

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

   Aber Sie definiert haben, dem Zuhörer zu:

   my_listener:
       class: Whatever
       arguments: [@my_other_service]

   Wenn der listener MyOtherService, dann wird PHP einen Fehler ausgeben, die Ihnen mitteilt, dass es falscher Klasse. Wenn Sie $container->get('my_service') Sie davon aus, dass sich der container ist wieder in der richtigen Klasse, und es dauert eine lange Zeit, um herauszufinden, dass seine' nicht.

5. Wenn Sie eine IDE, dann Typbestimmung fügt eine Menge zusätzliche Hilfe. Wenn Sie $service = $container->get('service'); dann die IDE hat keine Ahnung, was $service ist. Wenn Sie Spritzen mit

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

   dann die IDE weiß, dass $this->my_service ist eine Instanz von MyService, und bieten Hilfe bei der Methodennamen, Parameter, Dokumentation, etc.

6. Dein code ist einfacher zu Lesen. Alle Ihre Abhängigkeiten definiert sind, direkt dort an der Spitze der Klasse. Wenn Sie sind verstreut in der gesamten Klasse mit $container->get('service') dann kann es sehr viel schwieriger herauszufinden.

7. Dein code ist einfacher zu unit-testen. Wenn Sie die Injektion der service-container, die Sie haben, zu verhöhnen, der service-container, und konfigurieren Sie den mock zurück verspottet von den einschlägigen Diensten. Durch Einspritzen von den Diensten direkt, die Sie gerade verhöhnen die Dienstleistungen und injizieren Sie Sie überspringen eine ganze Schicht der Komplikation.

8. Werden nicht getäuscht Sie durch die "erlaubt es lazy loading" - Trugschluss. Sie können konfigurieren lazy loading zur Konfigurations-Ebene, nur durch markieren der service lazy: true.

Persönlich die einzige Zeit, die Injektion der service-container war die beste Lösung war, wenn ich versuche zu injizieren, die security-Kontext in eine Lehre Zuhörer. Dieser warf einen Zirkelbezug Ausnahme, denn die Benutzer wurden in der Datenbank gespeichert. Das Ergebnis war, dass Lehre und der Sicherheitskontext waren voneinander abhängig, zur compile-Zeit. Durch die Injektion der service-container, konnte ich rund um die zirkuläre Abhängigkeit. Jedoch, dies kann ein code smell, und es gibt Möglichkeiten, um ihn (zum Beispiel durch verwenden der event-dispatcher), aber ich gebe zu, die zusätzliche Komplikationen können die Vorteile überwiegen.

Neben allen Nachteilen erläutert, die von anderen (keine Kontrolle über die genutzten Dienste, Laufzeit, Zusammenstellung, fehlende Abhängigkeiten, etc.)

Gibt es eine Haupt-Grund, die Pausen der Hauptvorteil der Verwendung von DIC - Abhängigkeiten Ersatz.

Wenn service definiert ist, in der Bibliothek, Sie werden nicht in der Lage, Sie zu ersetzen Abhängigkeiten mit der lokalen Füllung Ihre Bedürfnisse.

Nur dieser Grund stark genug ist, um nicht zu Spritzen ganze DIC. Sie nur brechen ganze Idee des Ersetzens der Abhängigkeiten, da Sie HARDCODED! im service;)

BTW. Vergessen Sie nicht, zu verlangen interfaces im service-Konstruktor anstelle des spezifischen Klassen, so viel wie Sie können - wieder schönes Abhängigkeiten Ersatz.

EDIT: Abhängigkeiten Ersatz Beispiel

Service-definition in einige Verkäufer:

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

Ersatz in Ihrem app:

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

Diese ermöglicht das ersetzen von Verkäufer-Logik mit Ihren angepassten, aber vergessen Sie nicht, zur Umsetzung erforderlichen Klassen-interface. Mit hartcodierten Abhängigkeiten, die Sie sind nicht in der Lage zu ersetzen, die Abhängigkeit an einer Stelle.

Können Sie auch überschreiben vendor_dependency service, aber es ersetzt es in allen Orten, die nicht nur in vendor_service.