Validierungsgruppen vs. Serialisierungsgruppen

Zwei ÄHNLICH klingende, aber KOMPLETT unterschiedliche Konzepte werden ab hier wichtig – dieses kurze Kapitel schafft VOR den nächsten (Serialisierung, Kapitel 23-26) begriffliche Klarheit.

Validierungsgruppen: WELCHE Constraints gelten wann

GENAU wie in der Symfony-Schulung (Kapitel 24) erlauben Validierungsgruppen, Constraints NUR in bestimmten Situationen zu prüfen, z. B. ein Passwort-Feld NUR bei der Registrierung, NICHT beim Bearbeiten eines bestehenden Nutzers:

#[Assert\NotBlank(groups: ['registration'])]
private ?string $plainPassword = null;

Serialisierungsgruppen: WELCHE Felder sichtbar sind

Serialisierungsgruppen (Kapitel 23) steuern dagegen, WELCHE Properties überhaupt im JSON AUFTAUCHEN – ein internalNotes-Feld könnte etwa NUR für Admin-Nutzer sichtbar sein, für alle anderen komplett FEHLEN.

Konzept	Wirkung
Validierungsgruppe	Steuert, OB ein Constraint geprüft wird – betrifft NUR das Schreiben (POST/PUT/PATCH)
Serialisierungsgruppe	Steuert, OB ein Feld im JSON erscheint – betrifft LESEN (GET) UND Schreiben (welche Felder akzeptiert werden)

Achtung: Der HÄUFIGSTE Anfängerfehler: ein Feld über eine Serialisierungsgruppe zu VERSTECKEN in der Annahme, es sei damit auch VOR dem Schreiben geschützt – Serialisierungsgruppen betreffen die SICHTBARKEIT, NICHT automatisch die SCHREIBBARKEIT. Für ECHTEN Schreibschutz sind zusätzlich Zugriffskontrollen (security-Attribut, Block 6) nötig.

Beide Konzepte kombiniert

In der Praxis werden BEIDE gemeinsam genutzt: eine Serialisierungsgruppe project:write bestimmt, welche Felder ein POST-Request AKZEPTIERT, während EINE Validierungsgruppe zusätzlich steuert, WELCHE Constraints auf diesen akzeptierten Feldern greifen.

Tipp: Bei Unsicherheit hilft die Eselsbrücke: Validierung fragt "Ist der Wert GÜLTIG?", Serialisierung fragt "Soll das Feld ÜBERHAUPT sichtbar/annehmbar sein?" – ZWEI GRUNDVERSCHIEDENE Fragen.