State Processor (Kapitel 58) sind der BEVORZUGTE Weg für API-PLATFORM-spezifische Logik – für Logik, die UNABHÄNGIG davon greifen soll, WIE eine Entity gespeichert wird (auch außerhalb der API), sind Doctrine-Events die richtige Wahl.

Ein Beispiel: automatisches updatedAt

// Project.php - neues Feld
#[ORM\Column(nullable: true)]
#[Groups(['project:read'])]
private ?\DateTimeImmutable $updatedAt = null;

public function getUpdatedAt(): ?\DateTimeImmutable
{
    return $this->updatedAt;
}

public function setUpdatedAt(\DateTimeImmutable $updatedAt): static
{
    $this->updatedAt = $updatedAt;

    return $this;
}

Einen Event-Listener schreiben

<?php

declare(strict_types=1);

namespace App\EventListener;

use App\Entity\Project;
use Doctrine\Bundle\DoctrineBundle\Attribute\AsEntityListener;
use Doctrine\ORM\Event\PrePersistEventArgs;
use Doctrine\ORM\Event\PreUpdateEventArgs;
use Doctrine\ORM\Events;

#[AsEntityListener(event: Events::prePersist, entity: Project::class)]
#[AsEntityListener(event: Events::preUpdate, entity: Project::class)]
final class ProjectUpdatedAtListener
{
    public function prePersist(Project $project, PrePersistEventArgs $args): void
    {
        $project->setUpdatedAt(new \DateTimeImmutable());
    }

    public function preUpdate(Project $project, PreUpdateEventArgs $args): void
    {
        $project->setUpdatedAt(new \DateTimeImmutable());
    }
}

#[AsEntityListener] registriert den Listener AUTOMATISCH bei Doctrine – prePersist feuert beim ERSTMALIGEN Speichern, preUpdate bei JEDER nachfolgenden Änderung, UNABHÄNGIG davon, ob über die API, eine Fixture oder eine Konsolen-Kommando ausgelöst.

Wann Doctrine-Events statt Processor