Mit Laravel 13 können Sie nun die Eigenschaften $table, $fillable und $casts, die die meisten Models überladen, durch native PHP-Attribute ersetzen. Die Änderung betrifft mehr als ein Dutzend Framework-Features, von der Model-Konfiguration bis hin zu Event-Listenern und Mailables, und sie funktioniert, ohne bestehenden Code zu brechen.

Warum Laravel native Attribute hinzugefügt hat

Laravel verlässt sich schon lange auf „Magic Strings“ – Arrays von Spaltennamen oder versteckten Feldern, die am Anfang einer Model-Klasse stehen. Diese Arrays geben der IDE keinen Hinweis auf das zugrunde liegende Schema, sodass das Umbenennen einer Spalte unbemerkt bleiben kann. Durch die Verlagerung der Konfiguration in echten, typisierten Code bietet Laravel Entwicklern die Möglichkeit, den Klassenrumpf auf die Geschäftslogik zu konzentrieren, während der Editor Autovervollständigung, Typprüfung und Rename-Refactoring-Tools bereitstellt.

Das Framework liest Attribute über die Reflection-API von PHP aus und zwischenspeichert das Ergebnis, sodass der Laufzeit-Overhead effektiv bei Null liegt. Bestehende, auf Properties basierende Models funktionieren weiterhin genau wie bisher, was bedeutet, dass Sie die neue Syntax schrittweise einführen können.

Was Sie gewinnen

  • Typisierte Konfiguration – Attribute akzeptieren typisierte Argumente und eliminieren Magic Strings. Benennen Sie eine Spalte um, und die IDE zeigt Ihnen jede Stelle an, die Sie aktualisieren müssen.
  • Sauberere Klassenrümpfe – Die gesamte Konfiguration befindet sich oberhalb des Klassennamens; der Rumpf enthält nur noch Relationships, Scopes und Methoden.
  • Besseres IDE-Erlebnis – Autovervollständigung und statische Analyse funktionieren bei Attribut-Argumenten, was mit String-Arrays nicht möglich ist.
  • Keine Breaking Changes – Laravel liest sowohl die alten Properties als auch die neuen Attribute, sodass eine gemischte Codebasis problemlos läuft.

Schritt-für-Schritt-Migrationsleitfaden

  1. Identifizieren Sie das zu migrierende Model
    Öffnen Sie die Model-Datei. Wenn die ersten ein Dutzend Zeilen von $table, $fillable, $hidden oder einer casts()-Methode dominiert werden, ist es ein Kandidat.

  2. Fügen Sie die Attribut-Klassen hinzu
    Importieren Sie am Anfang der Datei die Attribut-Klassen, die den zu ersetzenden Properties entsprechen (z. B. Table, Fillable, Casts). Laravel liefert diese Attribute direkt mit.

  3. Ersetzen Sie Property-Deklarationen durch Attribute

    // Before
    protected $table = 'site_deployments';
    protected $fillable = ['site_id', 'server_id', 'status'];
    protected function casts(): array
    {
        return ['is_rollback' => 'boolean'];
    }
    
    // After
    #[Table('site_deployments')]
    #[Fillable(['site_id', 'server_id', 'status'])]
    #[Casts(['is_rollback' => 'boolean'])]
    class Deployment extends Model
    {
        // business logic only
    }
    

    Die Attribut-Syntax steht direkt über der Klassendeklaration. Entfernen Sie die ursprüngliche Property oder Methode, nachdem Sie bestätigt haben, dass das Attribut funktioniert.

  4. Führen Sie die Testsuite aus
    Überprüfen Sie, ob Mass-Assignment, Serialisierung und jegliches benutzerdefinierte Casting weiterhin wie zuvor funktionieren. Da das Attribut-Handling von Laravel zwischengespeichert wird, deutet ein fehlschlagender Test in der Regel auf einen Tippfehler in den Attribut-Argumenten hin.

  5. Committen und in kleinen Batches bereitstellen
    Pushen Sie das migrierte Model in einen Feature-Branch, mergen Sie es nach erfolgreichem Durchlaufen der CI-Pipeline und rollen Sie es auf einer Teilmenge von Servern aus. Da die alte Property-Syntax weiterhin unterstützt wird, verursacht jede versehentliche Referenz keinen Laufzeitfehler.

  6. Pro Namespace wiederholen
    Anstatt die gesamte Codebasis auf einmal umzuschreiben, verschieben Sie eine logische Gruppe von Models (z. B. alle abrechnungsrelevanten Entities) zu Attributen und wiederholen Sie den Vorgang für die nächste Gruppe. Dies begrenzt den „Blast Radius“ etwaiger Regressionen.

Tools und Sicherheitsnetze

  • Rector – Ein automatisiertes Refactoring-Tool, das die repetitive Property-Syntax in Attribute umwandeln kann. Führen Sie es auf einer Kopie der Codebasis aus, überprüfen Sie den Diff und wenden Sie die Änderungen an, die korrekt aussehen.
  • Automatisierte Tests – Die integrierten Test-Utilities von Laravel erkennen Unstimmigkeiten beim Mass-Assignment und der JSON-Ausgabe. Halten Sie diese nach jedem Migrationsschritt „grün“.
  • Feature Flags – Wenn Sie schnell zurückrollen müssen, kapseln Sie die neue Attribut-Nutzung hinter einem Flag, das zwischen der alten und der neuen Konfiguration umschaltet.

Wann Sie die Migration überspringen können

Wenn ein Projekt klein, stabil und selten verändert wird, wiegt der Vorteil sauberer Models den Aufwand der Konvertierung möglicherweise nicht auf. Die Attribut-Syntax ist optional; Sie können den klassischen Property-Ansatz unbegrenzt weiterverwenden. Umgekehrt reduziert bei aktiv entwickelten Anwendungen, insbesondere solchen mit großen Models oder häufigen Schemaänderungen, die frühzeitige Einführung von Attributen zukünftigen Reibungsverlust.

Was als Nächstes zu beachten ist

Die Attribut-Unterstützung von Laravel 13 erstreckt sich über Models hinaus auf Event-Listener, Notifications, Mailables und Broadcast-Events. Sobald die Community die Syntax in diesen Bereichen übernimmt, werden ähnliche Refactoring-Muster entstehen. Achten Sie auf den offiziellen Upgrade-Guide für neue Attribut-Klassen, die in zukünftigen Minor-Releases erscheinen.

Fazit: Laravel 13 bietet Ihnen einen Weg ohne Mehraufwand zu schlankeren, IDE-freundlicheren Models. Konvertieren Sie einen Namespace nach dem anderen, verlassen Sie sich auf Rector und Ihre Testsuite, und Sie werden am Ende Klassen erhalten, die sich wie Geschäftsspezifikationen lesen, anstatt wie bloße Konfigurations-Dump-Dateien.