Kapitel 37 zeigte die Beziehung NUR von der Task-Seite – dieses Kapitel ergänzt die INVERSE Seite auf Project, damit ein Projekt seine EIGENEN Tasks kennt.

Die tasks-Property ergänzen

use Doctrine\Common\Collections\ArrayCollection;
use Doctrine\Common\Collections\Collection;

// ... innerhalb der Klasse:

#[ORM\OneToMany(targetEntity: Task::class, mappedBy: 'project')]
#[Groups(['project:read'])]
private Collection $tasks;

public function __construct()
{
    $this->createdAt = new \DateTimeImmutable();
    $this->tasks = new ArrayCollection();
}

public function getTasks(): Collection
{
    return $this->tasks;
}

GENAU dasselbe ArrayCollection/Collection-Muster wie in der Symfony-Schulung (Kapitel 31) – mappedBy: 'project' verweist auf die project-Property in Task, GENAU umgekehrt zu inversedBy aus Kapitel 37.

Die Beziehung in der API-Antwort

curl -k https://localhost/api/projects/1

{
  "id": 1,
  "name": "Website-Relaunch",
  "tasks": [
    "/api/tasks/1",
    "/api/tasks/2"
  ]
}

tasks erscheint als ARRAY von IRI-STRINGS – NICHT als eingebettete Task-Objekte. Kapitel 40 erklärt, WARUM das die STANDARD-Darstellung ist und wie sich das GEZIELT ändern lässt.

Nur lesend: keine Write-Gruppe auf tasks

tasks gehört BEWUSST NUR zu project:read, NICHT zu project:write – Tasks werden über POST /api/tasks (Kapitel 37) angelegt, NICHT über ein verschachteltes Array beim Anlegen eines Projekts. Diese Entscheidung wird in Kapitel 45 vertieft.