Serie: PHP-Framework Symfony - Teil 2
Nachdem im ersten Teil unserer Symfony-Serie der Grundstein für die Anwendung gelegt wurde, steht in dieser Ausgabe die Anbindung an die Datenbank im Mittelpunkt. Wie gewohnt bietet Symfony auch für dieses Vorhaben eine Menge Werkzeuge und Hilfsmittel, um schnell zu einem Ergebnis zu gelangen.

- Serie: PHP-Framework Symfony - Teil 2
- Verbindungen schaffen
- Lesen von Werten
Die Kalenderansicht unseres Symfony-Projektes wollen wir in diesem Teil der Serie (den ersten Teil unserer Reihe über das Symfony-Framework finden Sie hier) um eine Datenbank erweitern. Benutzer und Termine werden am Ende dieser Ausgabe aus der Datenbank gelesen und im Kalender ausgegeben. Symfony ...
Die Kalenderansicht unseres Symfony-Projektes wollen wir in diesem Teil der Serie (den ersten Teil unserer Reihe über das Symfony-Framework finden Sie hier) um eine Datenbank erweitern. Benutzer und Termine werden am Ende dieser Ausgabe aus der Datenbank gelesen und im Kalender ausgegeben. Symfony macht uns diese Aufgabe relativ einfach.Das Framework bringt alles mit, um objektorientiert auf Datenbanken zuzugreifen. Als Basis dient hier das PHP-Framework Doctrine (www.doctrine-project.org), das nahtlos in Symfony integriert wurde und das den Model-Part des MVC-Musters eines Symfony-Projektes übernimmt.
Objektrelationales Mapping
Doctrine ist ein Framework für sogenanntes objektrelationales Mapping (ORM). Klassische PHP-Anwendungen nutzen die PHP-Datenbankbefehle, um auf die Tabellen zuzugreifen. Dies hat unter anderem den Nachteil, dass an diesen Stellen manuell SQL gebaut werden muss und die gesamte Verarbeitung der Daten nicht sauber objektorientiert gekapselt ist.

Innerhalb moderner Anwendungen sollte auch der Zugriff auf Datenquellen nur über Klassen und Objekte möglich sein. Doctrine ermöglicht dies, indem es dem PHP-Entwickler Klassen zur Verfügung stellt, die den Zugriff auf die Datenbank hinter einer sauberen objektorientierten Schnittstelle verbirgt. Für jede Datenbanktabelle werden automatisch eine oder mehrere Zugriffsklassen erstellt. In einer Symfony-Anwendung werden Sie nur sehr selten in die Verlegenheit kommen, SQL-Queries selbst zu schreiben. Das wird vom Framework übernommen.Das angesprochene objektrelationale Mapping ist allerdings nur eine der Schichten von Doctrine. Ebenso wichtig ist die Datenbankabstraktion. Einer der Nachteile von PHP ist das Fehlen einer einheitlichen Programmierschnittstelle für den Zugriff auf verschiedene Datenbanken.Dies hat sich in den letzten Jahren durch die Einführung von PDO zwar zum Positiven geändert, dennoch ist es auch heute noch in vielen Projekten gang und gäbe, dass auf die Datenbank direkt mit den entsprechenden Datenbankbefehlen (beispielsweise mysql_connect) zugegriffen wird. Dies führt unweigerlich zu einer direkten Bindung einer Software an einen Datenbankhersteller. Ein Wechsel ist dann nur mit massivem Aufwand machbar.Mit Doctrine stellt das kein Problem dar. Die Datenbankabstraktionsschicht sorgt dafür, dass Sie in einer Symfony-Anwendung die Datenbank ohne Probleme austauschen können. Auch um die korrekte Erstellung der SQL-Statements für die jeweilige Datenbank und der damit einhergehenden SQL-Dialekte kümmert sich Doctrine automatisch.
Datenbankverbindungsparameter
Der Clou an der Verbindungsdefinition innerhalb eines Symfony-Projektes ist die umgebungsabhängige Festlegung der Parameter. Symfony unterscheidet hierbei standardmäßig zwischen einer Produktiv-, Entwicklungs- und Testumgebung, je nachdem, wo die Anwendung läuft. In allen Symfony-Konfigurationsdateien können die Einstellungen für die einzelnen Umgebungen separat oder gemeinsam festgelegt werden.Im folgenden Listing wird beispielsweise für alle Umgebungen (all) festgelegt, dass Doctrine für den Datenbankzugriff genutzt wird. Für die Entwicklungsumgebung (dev) werden anschließend die genauen Datenbankzugriffsdaten im Konfigurationsbereich dsn definiert. Die gesamten Verbindungsdefinitionen sind in der Datei config/databases.yml zu finden. Das folgende Listing zeigt den Inhalt für unser Projekt.
all:
doctrine:
class: sfDoctrineDatabase
dev:
doctrine:
param:
dsn: mysql://root@localhost/
calendar
encoding: utf8
Eine Symfony-DSN (Datasource Name) hat grundsätzlich folgenden Aufbau datenbanktyp://username:passwort@hostname/datenbankname. Auf einem Produktivsystem werden wahrscheinlich andere Zugriffsparameter genutzt, in diesem Fall würde eine Erweiterung der databases.yml notwendig werden.
prod:
doctrine:
param:
dsn: mysql://
userx:wqheg12@192.1.1.1/calendar
encoding: utf8
Objektdefinition
Eine zentrale Aufgabe bei der Nutzung von Doctrine innerhalb eines Symfony-Projektes kommt der Datei schema.yml zu, die Sie im Verzeichnis config/doctrine finden können. Bei einem neu angelegten Projekt ist diese Datei, von einer einzelnen Zeile abgesehen, leer. Erweitern Sie die Datei so, dass das Ergebnis dem folgenden Listing entspricht. Beachten Sie, dass die Einrückung der Zeilen immer zwei Leerzeichen entspricht (keine Tabs) und stellen Sie sicher, dass Sie die Leerzeichen und Einrückungen entsprechend dem Listing übernehmen.
---
Appointment:
tableName: cal_appointment
columns:
name: { type: string(255) }
starts_at: { type: timestamp }
ends_at: { type: timestamp }
comment: { type: clob }
Mit dem Inhalt des Listings haben wir Symfony mitgeteilt, dass wir eine Model-Klasse Appointment nutzen wollen, deren Felder in der Datenbank abgelegt werden. Weiterhin wurde festgelegt, dass der Tabellenname in der Datenbank cal_appointment sein soll. Die angegebenen Datentypen der Felder müssen nicht zwingend mit den Typen übereinstimmen, die Sie wahrscheinlich von Ihrer Datenbank her kennen.Doctrine wählt den passenden SQL-Typ selbstständig anhand der verwendeten Datenbank. Unsere Appointment-Klasse besitzt im Moment vier Felder:
- name: Ein Kurztext mit maximal 255 Zeichen, der im Kalender angezeigt wird.
- starts_at: Die Startzeit des Termins.
- ends_at: Die Endzeit des Termins
- comment: Ein Kommentar, der einen Langtext enthalten kann.