Service-Konfiguration: Autowiring und Tags
Service-Konfiguration: Autowiring und Tags
~15 Min. Lesezeit Zuletzt aktualisiert am 8. August 2026
Autowiring funktioniert für die MEISTEN Fälle automatisch – dieses Kapitel behandelt die Fälle, in denen manuelle Konfiguration nötig wird, und die zentrale services.yaml-Datei dahinter.
config/services.yaml verstehen
services:
_defaults:
autowire: true
autoconfigure: true
App\:
resource: '../src/'
exclude:
- '../src/DependencyInjection/'
- '../src/Entity/'
- '../src/Kernel.php'Diese Standard-Konfiguration (bereits von Symfony Flex bei der Installation angelegt) registriert AUTOMATISCH JEDE Klasse unter src/ als Service – GENAU deshalb funktionierte ProjectStatistikService aus Kapitel 33 OHNE manuelle Registrierung. exclude nimmt Verzeichnisse aus, die KEINE Services enthalten (Entities sind reine Datenobjekte, kein Kernel-Bootstrapping-Code).
autowire und autoconfigure im Detail
| Option | Bedeutung |
|---|---|
| autowire: true | Konstruktor-Parameter werden AUTOMATISCH anhand ihres Typs aufgelöst (GENAU das, was wir seit Kapitel 8 nutzen). |
| autoconfigure: true | Bestimmte Interfaces/Basisklassen werden AUTOMATISCH mit passenden "Tags" versehen – z. B. wird ein Event Subscriber (Kapitel 37) automatisch als solcher erkannt, ohne manuelle Registrierung. |
Wann Autowiring NICHT ausreicht: mehrere Implementierungen
Gibt es MEHRERE Klassen, die DASSELBE Interface implementieren, kann Symfony NICHT automatisch entscheiden, welche gemeint ist:
interface BenachrichtigungsKanalInterface
{
public function sende(string $nachricht): void;
}
class EmailKanal implements BenachrichtigungsKanalInterface { /* ... */ }
class SlackKanal implements BenachrichtigungsKanalInterface { /* ... */ }Fordert ein Service-Constructor BenachrichtigungsKanalInterface $kanal an, wirft Symfony einen Fehler: "Mehrdeutiger Service". Lösung: EXPLIZITE Bindung in services.yaml, per Named Argument:
services:
App\Service\AlarmierungsService:
arguments:
$kanal: '@App\Service\Notification\EmailKanal'$kanal MUSS exakt dem Parameternamen im Constructor entsprechen, @ verweist auf einen Service anhand seiner ID (üblicherweise der volle Klassenname).
Scalar-Werte per Bind injizieren
Für Konfigurationswerte (nicht Objekte) wie eine maximale Aufgaben-Anzahl pro Projekt:
services:
_defaults:
autowire: true
autoconfigure: true
bind:
$maxAufgabenProProjekt: '%env(int:MAX_AUFGABEN_PRO_PROJEKT)%'class ProjectLimitService
{
public function __construct(
private readonly int $maxAufgabenProProjekt,
) {
}
}%env(int:...)% liest die Umgebungsvariable (GENAU wie DATABASE_URL in Kapitel 4), int: konvertiert den String-Wert automatisch zu int. bind in _defaults gilt für ALLE Services, deren Constructor einen Parameter mit GENAU diesem Namen hat – praktisch für weit verbreitete Konfigurationswerte.
Tags: Symfonys Plugin-Mechanismus
Tags markieren Services als "Erweiterung eines bestimmten Systems" – mit autoconfigure: true geschieht das MEIST automatisch über Interface-Erkennung (Event Subscriber in Kapitel 37, Voters aus Kapitel 29 werden z. B. automatisch am security.voter-Tag erkannt), manuelles Taggen ist nur für eigene, fortgeschrittenere Erweiterungspunkte nötig.
Tipp: Faustregel für dieses gesamte Kapitel: Verlassen Sie sich SOWEIT WIE MÖGLICH auf automatisches Autowiring/Autoconfigure – manuelle services.yaml-Einträge NUR dann, wenn Symfony tatsächlich einen "mehrdeutiger Service"-Fehler wirft oder ein Scalar-Wert injiziert werden muss.