Wer heute professionelle Erweiterungen schreibt, kommt an Contao 5 Doctrine Entities nicht vorbei. In Teil 1 haben wir das Fundament gegossen. Jetzt ziehen wir die Wände hoch. Wenn du schon länger mit Contao arbeitest, kennst du sicher die database.sql. Eine Datei, in der man händisch SQL-Befehle schreibt (CREATE TABLE...).

Die harte Wahrheit: Die manuelle SQL-Verwaltung ist tot. Der Einsatz von Contao 5 Doctrine Entities ist der einzig wahre Weg für moderne Contao-Entwicklung. Warum? Weil wir nicht mehr in flachen Tabellen denken, sondern in Objekten.

In diesem Teil nutzen wir Contao 5 Doctrine Entities, um unseren "Strandkorb" als intelligente PHP-Klasse zu modellieren. Wir setzen auf Doctrine ORM und PHP 8 Attribute. Das macht unseren Code sauberer, sicherer und unabhängig vom Datenbank-Typ.

Das ist der Plan:

Verstehen, warum Contao 5 Doctrine Entities besser sind als Arrays.
Die BeachChair Entity erstellen.
Das Repository einrichten.
Die Datenbank mittels Migration aktualisieren (ohne SQL zu schreiben!).

1. Die Entity: Dein Strandkorb als Objekt

Früher (in Contao 3/4) war ein Datensatz oft nur ein assoziatives Array: $arrStrandkorb['title']. Das Problem: Du weißt nie, welche Keys existieren. Tippfehler führen zu Bugs.

Mit Contao 5 Doctrine Entities ist ein Strandkorb eine Klasse. Sie hat Eigenschaften und Methoden. Die IDE hilft dir beim Autocomplete.

Erstelle den Ordner: /src/BeachsideBundle/src/Entity. Erstelle darin die Datei: BeachChair.php.

PHP

<?php

namespace Acme\BeachsideBundle\Entity;

use Acme\BeachsideBundle\Repository\BeachChairRepository;
use Doctrine\DBAL\Types\Types;
use Doctrine\ORM\Mapping as ORM;

#[ORM\Entity(repositoryClass: BeachChairRepository::class)]
#[ORM\Table(name: "tl_beach_chair")]
class BeachChair
{
    #[ORM\Id]
    #[ORM\GeneratedValue]
    #[ORM\Column]
    private ?int $id = null;

    #[ORM\Column(type: Types::INTEGER, options: ['unsigned' => true, 'default' => 0])]
    private int $tstamp = 0;

    #[ORM\Column(length: 255)]
    private ?string $title = null;

    #[ORM\Column(length: 10, unique: true)]
    private ?string $chairNumber = null;

    // Preis in Cent speichern (Best Practice um Rundungsfehler zu vermeiden!)
    #[ORM\Column(type: Types::INTEGER)]
    private int $pricePerDay = 0;

    #[ORM\Column(type: Types::TEXT, nullable: true)]
    private ?string $description = null;

    // Getter und Setter
    public function getId(): ?int
    {
        return $this->id;
    }

    public function getTstamp(): int
    {
        return $this->tstamp;
    }

    public function setTstamp(int $tstamp): static
    {
        $this->tstamp = $tstamp;
        return $this;
    }

    public function getTitle(): ?string
    {
        return $this->title;
    }

    public function setTitle(string $title): static
    {
        $this->title = $title;
        return $this;
    }

    public function getChairNumber(): ?string
    {
        return $this->chairNumber;
    }

    public function setChairNumber(string $chairNumber): static
    {
        $this->chairNumber = $chairNumber;
        return $this;
    }

    public function getPricePerDay(): int
    {
        return $this->pricePerDay;
    }

    public function setPricePerDay(int $pricePerDay): static
    {
        $this->pricePerDay = $pricePerDay;
        return $this;
    }

    public function getDescription(): ?string
    {
        return $this->description;
    }

    public function setDescription(?string $description): static
    {
        $this->description = $description;
        return $this;
    }
}

Analyse des Codes:

#[ORM\Table(name: "tl_beach_chair")]: Wir nutzen den Präfix tl_. Das ist extrem wichtig, damit Contao später im Backend (DCA) automatisch damit arbeiten kann.
PHP 8 Attribute: Statt langer Kommentare (Annotations) nutzen wir #[...]. Das ist performanter und lesbarer.
Typisierung: Wir wissen genau: pricePerDay ist ein int (Cent), kein float.

2. Das Repository: Der Daten-Manager

Wo holen wir die Daten her? Im Repository. Während die Entity die Datenstruktur ist, ist das Repository der Wächter, der Datenbank-Abfragen macht.

Erstelle den Ordner: /src/BeachsideBundle/src/Repository. Erstelle darin: BeachChairRepository.php.

PHP

<?php

namespace Acme\BeachsideBundle\Repository;

use Acme\BeachsideBundle\Entity\BeachChair;
use Doctrine\Bundle\DoctrineBundle\Repository\ServiceEntityRepository;
use Doctrine\Persistence\ManagerRegistry;

/**
 * @extends ServiceEntityRepository<BeachChair>
 */
class BeachChairRepository extends ServiceEntityRepository
{
    public function __construct(ManagerRegistry $registry)
    {
        parent::__construct($registry, BeachChair::class);
    }

    public function save(BeachChair $entity, bool $flush = false): void
    {
        $this->getEntityManager()->persist($entity);

        if ($flush) {
            $this->getEntityManager()->flush();
        }
    }

    public function remove(BeachChair $entity, bool $flush = false): void
    {
        $this->getEntityManager()->remove($entity);

        if ($flush) {
            $this->getEntityManager()->flush();
        }
    }
    
    // Später fügen wir hier Methoden hinzu wie:
    // public function findAvailableChairs($startDate, $endDate) { ... }
}

Profi-Tipp: Durch extends ServiceEntityRepository bekommen wir Methoden wie find(), findAll() oder findOneBy() geschenkt. Wir müssen kein SQL schreiben, um einen Strandkorb anhand der ID zu finden.

3. Konfiguration: Mapping aktivieren

Standardmäßig scannt Doctrine in Symfony-Apps automatisch src/Entity. Da wir uns in einem Bundle befinden, müssen wir sicherstellen, dass Doctrine unsere Klassen findet.

Wenn du die Standard-Struktur aus Teil 1 eingehalten hast, sollte es "out of the box" funktionieren. Falls nicht, müssen wir der BeachsideExtension.php noch sagen, dass sie Doctrine konfigurieren soll. Aber wir probieren es erst einmal ohne (der moderne "Auto-Mapping" Weg).

4. Die Migration: Vom Code zur Datenbank

Jetzt kommt der magische Moment. Wir haben PHP-Code geschrieben, aber unsere Datenbank ist noch leer. Vergiss phpMyAdmin. Vergiss CREATE TABLE.

Öffne dein Terminal und führe folgenden Befehl im Root-Verzeichnis aus:

vendor/bin/contao-console doctrine:schema:update --dump-sql

Abstrakte Datenbank-Tabellen bauen sich auf

Was passiert jetzt? Doctrine vergleicht deine PHP-Klasse BeachChair mit der echten Datenbank. Es merkt: "Huch, die Tabelle tl_beach_chair fehlt!" und generiert dir das SQL:

SQL

CREATE TABLE tl_beach_chair (id INT AUTO_INCREMENT NOT NULL, tstamp INT UNSIGNED DEFAULT 0 NOT NULL, title VARCHAR(255) NOT NULL, ... PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8mb4 ...;

Wenn das SQL gut aussieht, feuern wir es ab:

vendor/bin/contao-console doctrine:schema:update --force

(Hinweis: In Produktionsumgebungen nutzen wir doctrine:migrations:diff und migrate, aber für die Entwicklung ist schema:update --force der schnelle Weg.)

5. Check: Ist die Tabelle da?

Du kannst jetzt in deine Datenbank schauen (ja, jetzt darfst du phpMyAdmin oder Adminer kurz öffnen). Du wirst sehen: Die Tabelle tl_beach_chair existiert. Sauber definiert, mit den richtigen Indizes. Und das alles, ohne eine Zeile SQL geschrieben zu haben.

#doctrine

Contao 5 Doctrine Entities: Moderne Datenmodellierung statt SQL-Chaos