Die PersistentObject-Komponente bietet Ihnen eine weitere Abstraktionsschicht zwischen dem Datenbanksystem und der Applikationslogik.
7 ORM mit PersistentObject
In Kapitel 6, »Datenbankanbindung«, haben Sie den Zugriff auf ein relationales Datenbanksystem mit Hilfe der Database-Komponente kennengelernt. Nun werden wir Ihnen die PersistentObject-Komponente vorstellen, mit der eine weitere Abstraktionsschicht zwischen dem Datenbanksystem und der Applikationslogik gezogen werden kann.
Über sogenanntes Objekt-Relationales-Mapping (ORM) erlaubt es die Komponente PersistentObject, PHP-Objekte (für Sie als Entwickler weitestgehend transparent) in einer relationalen Datenbank abzulegen. Mit Hilfe der Komponente werden Ihnen die typischen Aufgaben beim Zugriff auf Objekte in der Datenbank erleichtert, indem das
- Laden,
- Speichern,
- Löschen,
- Aktualisieren und
- Suchen
von Objekten auf einfachem Wege ermöglicht wird.
7.1 Modell-Klassen 
Wie Sie bereits aus Kapitel 3, »Die Applikationsbasis«, wissen, baut das GP-Blog auf einer Implementierung des Model-View-Controller-Entwurfsmusters auf, wobei die Controller-Architektur bereits im gleichen Kapitel vorgestellt wurde. In diesem Kapitel widmen wir uns der Umsetzung der Modelle, also den Datenobjekten, welche im Laufe der Applikation von Controller-Objekten manipuliert und von der View dargestellt werden. Das View-Modul wird passend dazu in Kapitel 8, »Template«, entwickelt.
Im Galileo-Press-Blog werden drei verschiedene Modell-Klassen verwendet: gpBlogEntry zur Repräsentation eines Blog-Eintrags, gpBlogComment, deren Instanzen einen Kommentar darstellen, und gpBlogTag, mit deren Hilfe ein Tag modelliert wird. Da Objekte dieser Klassen reine Datenspeicher darstellen, sind sie nur sehr rudimentär implementiert, machen allerdings erneut Gebrauch vom Konzept der Virtual Properties, welches Sie bereits in Kapitel 2, »Einführung in eZ Components«, und in Kapitel 3, »Die Applikationsbasis«, kennengelernt haben.
class gpBlogEntry
{
protected $properties = array(
"id" => null,
"body" => null,
"date" => null,
"title" => null,
);
public function __construct()
{
}
public function getState()
{
return $this->properties;
}
public function setState( array $state )
{
foreach ( $state as $propertyName => $propertyValue )
{
if ( isset( $this->$propertyName ) )
{
$this->properties[$propertyName] =
$propertyValue;
}
}
}
public function __get( $propertyName )
{
if ( isset( $this->$propertyName ) )
{
return $this->properties[$propertyName];
}
throw new gpBlogPropertyNotFoundException(
$propertyName
);
}
public function __set( $propertyName, $propertyValue )
{
if ( $propertyName === "id" )
{
throw new gpBlogPropertyPermissionException(
$propertyName,
gpBlogPropertyPermissionException::READ
);
}
if ( isset( $this->$propertyName ) )
{
$this->properties[$propertyName] = $propertyValue;
return;
}
throw new gpBlogPropertyNotFoundException(
$propertyName
);
}
public function __isset( $propertyName )
{
return array_key_exists(
$propertyName,
$this->properties
);
}
}Listing 7.1 Die gpBlogEntry-Modell-Klasse
Die Eintragsklasse implementiert die Overloading-Methoden __get(), __set() und __isset() zum Zugriff auf die Virtual Properties der Klasse: $id, $body, $date und $title. Die Kapselung dieser Attribute mit Hilfe des Virtual-Property-Konzepts erfolgt an dieser Stelle zum Schutz des Attributs $id, welches ausschließlich von der Datenbank vergeben wird. Wie Sie im vorhergehenden Kapitel gesehen haben, verwenden wir einen auto_increment-Mechanismus dafür. Falls versucht wird, das so geschützte Attribut direkt zu verändern, wird eine gpBlogPropertyPermissionException geworfen; der Lese-Zugriff hingegen ist erlaubt. Die genannte Exception erweitert nach dem Konzept, das wir bereits in Kapitel 3, »Die Applikationsbasis«, verwendet haben, lediglich die passende eZ Components-Exception zum Zweck der Unterscheidung beim Fangen der Exceptions im Haupt-Controller.
Neben dem Virtual-Property-Zugriff implementiert die gezeigte Modell-Klasse zwei weitere Methoden namens getState() und setState(). Diese werden von PersistentObject verwendet, um den Status eines Objekts zu extrahieren und in die Datenbank zu speichern – getState() beziehungsweise, um auf dem umgekehrten Weg den Status des Objekts wiederherzustellen – setState(). Beide Methoden werden im Interface ezcPersistentObject definiert und arbeiten mit Array-Repräsentationen des Objekt-Status, indem die Attribute des Modells in einem assoziativen Array gespeichert werden, das die Attributnamen als Schlüssel benutzt. getState() gibt diese Objektrepräsentation zurück, setState() verarbeitet sie und setzt die entsprechenden Werte der Objekt-Attribute. Auch in diesen beiden Methoden kommt die Verwendung von Virtual Properties der Entwicklung zugute, denn intern wird sowieso nur mit einem $properties-Array gearbeitet.
