Teil 2: Serie: PHP-Frameworks Teil 2 - Symfony im Detail
- Serie: PHP-Frameworks Teil 2 - Symfony im Detail
- Teil 2: Serie: PHP-Frameworks Teil 2 - Symfony im Detail
- Teil 3: Serie: PHP-Frameworks Teil 2 - Symfony im Detail
- Teil 4: Serie: PHP-Frameworks Teil 2 - Symfony im Detail
- Teil 5: Serie: PHP-Frameworks Teil 2 - Symfony im Detail
Der große Vorteil an diesem Vorgehen ist die Stabilität des Gesamtsystems. Bereits in den ersten Versionen des Frameworks stand dadurch eine robuste Plattform für die Entwicklung von PHP-Anwendungen zur Verfügung. Model Der Zugriff auf Daten einer Datenbank ist für aktuelle Anwendungen ein ...
Der große Vorteil an diesem Vorgehen ist die Stabilität des Gesamtsystems. Bereits in den ersten Versionen des Frameworks stand dadurch eine robuste Plattform für die Entwicklung von PHP-Anwendungen zur Verfügung.
Model
Der Zugriff auf Daten einer Datenbank ist für aktuelle Anwendungen ein sehr wichtiger Part der täglichen Entwicklerarbeit. Die Möglichkeiten von Symfony auf diesem Gebiet sind eine der Hauptstärken des Frameworks. Bereits seit den ersten frei verfügbaren Versionen ist ein Framework für objektrelationales Mapping mit an Bord.Wie bereits erwähnt, ist auch der Datenbank- Layer von Symfony keine reine Eigenentwicklung, sondern basiert teilweise auf anderen, frei verfügbaren Open-Source-Lösungen. Symfony kapselt diese in einfach zu nutzende Klassen und integriert diese nahtlos in das Framework.Die ersten Versionen von Symfony basierten noch ausschließlich auf dem ORM-Framework Propel. Mit der Version 1.2 hat zudem Doctrine als Datenbankschicht Einzug gehalten, die zuvor nur als Plugin nachrüstbar war. Bereits Propel stellt ein sehr mächtiges Werkzeug zum objektorientierten Zugriff auf Datenbanken dar.
Doctrine legt hier aber nochmals eine Schippe drauf. Der Leistungsumfang, die Flexibilität und die Zugriffsmöglichkeiten auf Datenbestände ist enorm. Dennoch ist die Geschwindigkeit beachtlich. Welches Datenbank-Framework zum Einsatz kommt, kann jeder selbst entscheiden. Unabhängig von der Wahl der Datenbankschicht verläuft die anschließende Arbeit auf ähnliche Art und Weise.
Die Grundlage ist immer die Beschreibung des Datenbank-Schemas, die in einer Text-Datei im YAML-Format erfolgt. Das folgende Listing zeigt ein Beispiel für die Beschreibung zweier Klassen in der Doctrine-Notation, die durch eine 1:n-Beziehung miteinander verbunden sind.
Author:
columns:
id: { type: integer, primary:
true, autoincrement: true }
contact_id: { type: integer(4) }
first_name: { type: string(255) }
last_name: { type: string(255) }
Book:
columns:
id: { type: integer, primary: true, autoincrement: true }
name: { type: string(255) }
user_id: { type: integer(4) }
relations:
Author:
foreignAlias: BooksSo werden alle speicherbaren Objekte definiert. Das gezeigte Beispiel enthält die beiden Objekte/Tabellen Author und Book, mit der Beschreibung der zugeordneten Eigenschaften. Für jede Eigenschaft werden verschiedene Attribute in geschweiften Klammern gesetzt, im Beispiel hauptsächlich Typ und Länge der Tabellenfelder.
In der Praxis sind hier deutlich mehr Attribute üblich, so sind auch Indizes, Constraints, Standardwerte und Weiteres über die Definitionen beschreibbar. Je nach Datenbank-Framework werden unterschiedliche Funktionen unterstützt. Doctrine bietet hier bereits out-of-the-box ausgefeilte Erweiterungen, die vieles automatisieren.
So sind die Verwaltung von Baumstrukturen oder die Versionierung von Daten in der Datenbank bereits in Doctrine integriert. Die Definition der Datenbankstruktur ist allerdings nur der erste Schritt, viel interessanter ist, was sich aus diesem Schema so alles erzeugen lässt.
Der Aufruf eines Kommandozeilenbefehls genügt, um beispielsweise komplette Datenbankzugriffsklassen für jede Datenbanktabelle zu generieren.
$> symfony doctrine:build-model fron
tend
