Magento 2 Experten — Hyvä Theme, Tailwind CSS & SEO aus einer Hand ›

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

config/services.yaml
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

OptionBedeutung
autowire: trueKonstruktor-Parameter werden AUTOMATISCH anhand ihres Typs aufgelöst (GENAU das, was wir seit Kapitel 8 nutzen).
autoconfigure: trueBestimmte 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:

config/services.yaml
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:

config/services.yaml
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.