Seite 12 - Symfony

Doctrine Repositories mit reinen Mocks zu testen prüft selten die eigentliche Query. Eine In-Memory-SQLite-Datenbank führt DQL und Query-Builder-Aufrufe echt aus, ganz ohne Datenbankserver, und macht Repository-Tests in Millisekunden statt Sekunden lauffähig.

Der ObjectNormalizer der Symfony Serializer-Komponente liest per Reflection alle Properties eines Objekts aus und baut daraus ein Array, was für einfache DTOs hervorragend funktioniert. Sobald ein Objekt aber ein Value Object mit eigener interner Struktur ist, eine polymorphe Klassenhierarchie abbildet oder Objekte referenziert, die wiederum aufeinander zeigen, stößt diese generische Reflection-Logik an klare Grenzen. Dieser Artikel zeigt, wie man mit NormalizerInterface und DenormalizerInterface eigene Transformationen schreibt, wie man deren Priorität gegenüber eingebauten Normalizern steuert und wie man Zirkelreferenzen kontrolliert auflöst, statt in eine Endlosschleife zu laufen.

Die hexagonale Architektur — auch bekannt als Ports and Adapters — befreit die Domänenlogik von der Kopplung an Frameworks, Datenbanken und externe Services. In Symfony lässt sie sich mit PHP-Interfaces als Ports und Symfony-Services als Adapters präzise umsetzen: vollständig testbarer Domänencode ohne ein einziges Framework-Import in der Kernlogik.

SaaS-Anwendungen müssen mehrere Kunden auf derselben Codebasis betreiben, ohne dass Daten zwischen Mandanten sichtbar werden. Symfony bietet keine eingebaute Multi-Tenancy-Lösung — aber mit einem klaren Tenant-Resolver, der richtigen Doctrine-Strategie und konsequenter Request-Scoping-Architektur entsteht ein System, das sicher, wartbar und skalierbar für beliebig viele Mandanten ist.

Das Symfony Form-Component ist eines der mächtigsten und komplexesten im Ökosystem. Wer nur Built-in-Types nutzt, verschenkt die Hälfte des Potenzials. Custom Form Types kapseln Wiederverwendbarkeit, Data Transformers überbrücken die Kluft zwischen Formulareingabe und Domänenobjekten — ohne Boilerplate in jedem einzelnen Formular.

Eine rollen-basierte Zugriffskontrolle mit ROLE_ADMIN und ROLE_USER reicht in der Praxis selten aus. Wenn ein Benutzer nur seine eigenen Ressourcen bearbeiten darf, nur Mitglieder seines Teams Zugriff haben oder Berechtigungen von Zustand des Objekts abhängen, ist der Symfony Security Voter die richtige Antwort.

Ein sauberer Symfony 7 Upgrade ist kein Sprung ins Ungewisse, sondern ein wiederholbarer Prozess: Deprecations systematisch aufspueren, Composer-Constraints kontrolliert loesen, Config-Aenderungen einzeln pruefen und jeden Schritt mit funktionalen Tests absichern, bevor der Rollout in Produktion geht.

Eine Legacy Symfony 4 Migration scheitert selten an fehlendem Wissen ueber neue Features, sondern an der alten Bundle-Struktur, Sensio-Annotationen und fehlendem Flex. Wer die Reihenfolge kennt, in der Struktur, Konfiguration und Abhaengigkeiten modernisiert werden, bringt eine seit Jahren gewachsene Anwendung sicher auf einen aktuellen Symfony-Stand.

CQRS trennt lesende von schreibenden Operationen, aber diese Trennung bleibt halbherzig, solange beide über denselben Messenger-Bus mit identischer Middleware laufen. Zwei separate Busse, command.bus und query.bus, mit jeweils eigenem Middleware-Stack machen die Trennung nicht nur konzeptionell, sondern auch technisch konsequent und verhindern, dass Query-Handler unnötig in Transaktionen laufen oder Command-Handler ohne Validierung durchrutschen.

Der Symfony RateLimiter schützt Endpunkte zuverlässig vor Missbrauch, aber nur, wenn der gewählte Storage-Backend zur tatsächlichen Infrastruktur passt. In-Memory-Storage ist für Tests gedacht und zählt Anfragen nur innerhalb eines einzelnen PHP-Prozesses, was hinter einem Load Balancer mit mehreren Server-Instanzen faktisch bedeutet, dass ein Angreifer das Limit einfach mit der Anzahl der Instanzen multiplizieren kann. Dieser Artikel vergleicht In-Memory-Storage, den generischen Cache-Adapter und Redis als geteilten Zustand, zeigt die konkrete Konfiguration der RateLimiterFactory und erklärt den praktischen Unterschied zwischen Sliding-Window- und Token-Bucket-Policy.