Artikel
von Patrick Froch

Contao 4: Entity-Grundlagen

Nachdem wir gestern im Artikel "Contao 4: Erweiterung als Bundle" gesehen haben, wie man eine Erweiterung für Cotnao 4 als Bundle anlegt, möchte ich heute auf die Grundlagen der Arbeit mit dem ORM von Doctrine eingehen. Über Doctrine im Zusammenhang mit Symfony habe ich bereits im Beitrag "Doctrine: Eine Einführung" geschrieben. Heute soll es um das Anlegen und Verwenden von Entities in Contao 4 gehen.

Vorbereitung

Wir bewegen uns auch heute wieder im AcmeTestBundle, die Struktur sollte noch von gestern bekannt sein. Dort habe ich gesagt, dass ich weiterhin alle Klassen unter classes speichern möchte. Diese Entscheidung muss ich heute leider schon wieder ein Stück weit revidieren. Es gibt in Symfony für die meisten Dinge einen einfachen Weg und viele weitere, die aber viel komplizierter sind. Es wäre möglich, die Entites unter classes zu speichern, man müsste aber wesentlich mehr konfigurieren. Ich werde mich deshalb am vorgesehenen Weg orientieren.

In Symfony müssen die Entities eines Bundls unter `Entity/` liegen, damit sie automatisch gefunden werden!

Installation

Als erstes müssen einige Pakete installiert werden. Wir ergänzen die composer.json folgendermaßen:

Nun noch einmal composer update ausführen.

Konfiguration

Als nächstes muss der Doctrin-ORM noch konfiguriert werden. Wir passen dazu die Datei app/config/config.yml an.

In Zeile 14 beginnt die neue ORM-Setktion und in Zeile 18 steht unser Bundle. Da die Entites im Ordner src/Acme/TestBundle/Entity/ liegen, werden sie nun automatisch gefunden.

Anlegen der Entity-Klasse

Nun legen wir eine Entity-Klasse mit dem Namen src/Acme/TestBundle/Entity/TlAcmeArea.php an.

Wir definieren hier die 5 Felder id, tstamp, city, postal und country. Zusätzlich sind noch entsprechende Getter und Setter vorhanden. Ich verzichte für die Erzeugung der Methoden auf den Einsatz der Symfony-Konsole. Die meisten IDEs leisten hier hervorragende Dienste. Ich gehe davon aus, dass für die Tabelle ein DCA existiert und sie ganz normal über Contao erzeugt wurde. Da dies schon einige Male besprochen wurde, gehe ich nicht weiter darauf ein. Wer hier genaueres Wissen möchte, wird z.B. im Artikel "Contao: Eigenen Backend-Menüpunkt" fündig.

Verwenden der Entity-Klasse

Nun können wir z.B. in einem Inhaltselement ganz leicht mit unserer Entity-Klasse arbeiten.

Dies ist natürlich nur ein Beispiel für die Verwendung des ORM. Die Feinheiten können in der Dokumentation nachgelesen werden.

Wenn man viele Änderungen an der Datenbank vornehmen muss, sollte man nicht jedes Mal $entityManager->flush(); aufrufen. Es geht wesentlich schneller, wenn man es nur einmal am Ende aufruft!

Ausgabe

Die Ausgabe könnte dann z.B. so aussehen:

Das soll als keine Einführung erst einmal reichen. Wenn ich die Zeit finde, werden bald weitere Artikel folgen.

Zurück

Einen Kommentar schreiben

Kommentar von Jörg |

Danke für diesen interessanten Beitrag.

Mich würde noch interessieren, was der Vorteil von Symfony Entities gegenüber den Models von Contao ist.

Antwort von Patrick Froch

Ich kratze auch erst an der Oberfläche, aber ich würde sagen: dass auffälligste Merkmal ist, dass Doctrine wesentlich besser dokumentiert ist. Außerdem besteht Doctrine ja nicht nur aus den Entities. Insgesamt ist Doctrine viel umfangreicher, der Entwicklerkreis ist größer, es ist besser getestet las die Contao-Models. Natürlich ist es auch viel komplizierter. 

Es gibt hier aber keine "entweder-oder". In Contao 4.3, setzen die Contao-Datenbank-Mechanismen auf Doctrine auf. In sofern ist es für Contao erst einmal egal, was Du nutzt. Langfristig und wenn keine Abwärtskompatibilität benötigt wird, würde ich ganz klar Doctrine empfehlen.

Ich hoffe ich konnte mit meinem gesunden Halbwissen etwas weiter helfen. ;)

Kommentar von Jörg |

Ja, das hilft mir weiter. Wenn Contao die Models in Zukunft nicht mehr verwendet, ist es natürlich sinnvoll, sich auch jetzt schon mit Doctrine zu beschäftigen. Danke.

Was ist die Summe aus 1 und 6?