Dependency Injection klingt für viele erst einmal nach Architektur-Theorie. In Shopware-Projekten ist sie aber etwas sehr Praktisches: der Unterschied zwischen Code, den du sauber erweitern kannst, und Code, der dir bei jedem Umbau im Weg steht. Gerade in Plugins, Commands, Controllern oder Subscriber-Klassen entscheidet DI oft darüber, ob Weiterentwicklung ruhig oder chaotisch läuft.
Was Dependency Injection in Shopware praktisch bedeutet
Die Grundidee ist einfach: Eine Klasse erzeugt ihre Abhängigkeiten nicht selbst, sondern bekommt sie von außen übergeben. In Shopware passiert das in der Regel über den Symfony-Container.
Statt so zu arbeiten:
$service = new ProductService();landet die Verantwortung für die Erstellung beim Container. Deine Klasse konzentriert sich dann auf ihre Aufgabe statt auf den Bau ihrer Umgebung.
Warum direkte Abhängigkeiten später teuer werden
Harte new-Aufrufe wirken am Anfang schnell und unkompliziert. Später werden sie oft teuer, weil sie:
- Tests unnötig schwer machen
- Klassen eng an konkrete Implementierungen koppeln
- Refactorings riskanter machen
- Wiederverwendung im Plugin erschweren
Genau das wird in Shopware schnell sichtbar, sobald Logik nicht mehr nur an einer Stelle lebt, sondern in mehreren Services, Events oder API-Pfaden wieder auftaucht.
Woran du schlechte DI in Plugin-Code erkennst
In gewachsenen Projekten tauchen immer wieder dieselben Muster auf:
- Controller oder Subscriber enthalten eigentliche Geschäftslogik
- der Container wird direkt in Klassen gezogen und wie ein Service-Locator benutzt
- eine Klasse hat so viele Abhängigkeiten, dass ihre Verantwortung unklar wird
- statische Helper ersetzen saubere Services
Wenn du so etwas in deinem Plugin-Code siehst, ist DI meistens nicht wirklich umgesetzt, sondern nur oberflächlich vorhanden.
So sieht ein sauberer Shopware-Service aus
Ein guter Service hat eine klar abgegrenzte Aufgabe und bekommt nur die Abhängigkeiten, die er wirklich braucht:
namespace SwagExample\Service;
final class PriceLabelBuilder
{
public function __construct(
private CurrencyFormatter $currencyFormatter
) {
}
public function build(float $price, string $currencyIso): string
{
return $this->currencyFormatter->format($price, $currencyIso);
}
}Der Vorteil ist nicht nur sauberer Code. Diese Struktur macht die Klasse auch deutlich einfacher testbar und austauschbar.
Dependency Injection und Tests greifen direkt ineinander
Sobald Services sauber injiziert werden, kannst du sie isoliert testen, statt immer halbe Framework-Strukturen mitzuschleppen. Genau deshalb hängen DI, objektorientiertes PHP in Shopware und Unit Tests für Shopware-Plugins direkt zusammen.
Wenn Tests in deinem Projekt unnötig schwer sind, liegt die Ursache oft nicht zuerst im Test selbst, sondern in zu stark gekoppeltem Code.
Wann Dependency Injection allein nicht reicht
DI löst nicht automatisch jedes Architekturproblem. Wenn eine Klasse fachlich zu viel Verantwortung trägt, helfen auch sauber injizierte Services nur begrenzt. Dann musst du die Struktur selbst verbessern:
- Verantwortlichkeiten trennen
- Seiteneffekte reduzieren
- klare Schnittstellen definieren
- Framework-Code und Business-Logik sauber auseinanderhalten
DI ist also kein Selbstzweck, sondern ein Hebel für bessere Struktur.
Wann sich saubere Plugin-Architektur besonders lohnt
Sobald individuelle Funktionen, Schnittstellen oder komplexere Geschäftslogik ins Spiel kommen, zahlt sich gute Struktur doppelt aus. Wenn du Erweiterungen nicht nur schnell, sondern langfristig wartbar bauen willst, ist eine saubere Shopware Plugin-Entwicklung meist sinnvoller als spontane Workarounds im Bestand.
Fazit
Dependency Injection ist in Shopware keine Kür, sondern eine sehr praktische Grundlage für wartbaren Code. Sie reduziert harte Abhängigkeiten, verbessert die Testbarkeit und macht Erweiterungen robuster. Wenn dein Plugin-Code heute schon schwer veränderbar wirkt, lohnt sich fast immer zuerst ein Blick auf die Abhängigkeitsstruktur.
FAQ
Warum ist Dependency Injection in Shopware so wichtig?
Weil Shopware stark servicebasiert arbeitet. Saubere DI macht Plugins, Subscriber und Services leichter testbar, austauschbar und wartbar.
Sollte ich in Shopware den Container direkt in meinen Klassen verwenden?
Nur sehr zurückhaltend. In normalem Anwendungs-Code ist Constructor Injection fast immer die sauberere Lösung als ein versteckter Service-Locator.
Woran merke ich, dass mein Plugin von besserer DI profitieren würde?
Wenn Klassen schwer testbar sind, zu viele Aufgaben tragen oder Änderungen an einer Stelle sofort mehrere andere Teile kaputtmachen, ist die Abhängigkeitsstruktur meist ein Kernproblem.