Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Geleitwort des Fachgutachters
Vorwort
1 Einleitung
2 Einführung in eZ Components
3 Die Applikationsbasis
4 Fehlerbehandlung und Debugging
5 Konfiguration
6 Datenbankanbindung
7 ORM mit PersistentObject
8 Template
9 Übersetzung
10 Benutzereingaben validieren
11 Authentifizierung
12 Bildverarbeitung
13 Archive und Dateien
14 Mail
15 Logging
16 Diagramme
17 Feeds und Caching
18 Setup
A Inhalt der Buch-CD
Stichwort
Download: - ZIP, ca. 2,7 MB
Ihre Meinung?
<< zurück | Galileo Computing / <openbook> /eZ Components | vor >>
eZ Components von Tobias Schlitt, Kore Nordmann Das Entwickler-Handbuch
eZ Components geb., mit CD 454 S., 39,90 Euro Galileo Computing ISBN 978-3-8362-1073-7 |
| 7 ORM mit PersistentObject
|  | 7.1 Modell-Klassen
|  | 7.2 Konzepte
|  |  | 7.2.1 Active Record
|  |  | 7.2.2 Row Data Gateway
|  |  | 7.2.3 Persistent Object
|  | 7.3 Konfiguration
|  |  | 7.3.1 Basiskonfiguration
|  |  | 7.3.2 Relationen beschreiben
|  | 7.4 Benutzung
|  |  | 7.4.1 Eine Persistenz-Sitzung erzeugen
|  |  | 7.4.2 Objekte auffinden
|  |  | 7.4.3 Objekte manipulieren
|  | 7.5 Erweiterte Möglichkeiten
|  |  | 7.5.1 Über Abfragen manipulieren
|  |  | 7.5.2 Werte auffrischen
|  |  | 7.5.3 Direkt mit der Datenbank arbeiten
|  | 7.6 Fazit
## 7.2 Konzepte Das Konzept eines objekt-relationalen Mappings ist weit verbreitet in der objektorientierten Programmierung. Bevor Sie den Mechanismus der eZ Components für diesen Zweck kennenlernen, wollen wir einige grundlegende Vorgehensweisen in dieser Richtung vorstellen und anschließend die Gedanken hinter PersistentObject verdeutlichen. ### 7.2.1 Active Record Das wohl bekannteste Entwurfsmuster zur Implementierung eines ORM-Mechanismus trägt den Namen Active Record. In diesem Entwurfsmuster werden die Modell-Objekte selbst mit Methoden ausgestattet, welche den Zugriff auf die Datenbank ermöglichen. So enthält eine Modell-Klasse typischerweise Methoden zum Abspeichern des Modells und zum Laden eines bestimmten Datensatzes aus der Datenbank. Zusätzlich werden häufig Methoden implementiert, die das Auffinden verbundener Objekte ermöglichen. So würde im GP-Blog die Klasse ezcBlogEntry Methoden wie save(), update() und delete() enthalten, aber auch getComments() zum Auffinden der Kommentare, die zu einem Eintrag abgegeben wurden. In vielen Fällen enthält eine Modell-Klasse außerdem statische Methoden, die dem Auffinden verschiedener Mengen dieser Klasse dienen. So könnte die Eintragsklasse eine Methode namens getLatestPosts() enthalten, welche die zehn aktuellsten Beiträge aus der Datenbank lädt. Generell sind der Ansatz des Active-Record-Entwurfsmusters, die mit einem Modell-Objekt verbundene Speicherlogik und gegebenenfalls weitere Applikationslogik direkt an das Objekt zu binden. Mehr zum Active Record Pattern können Sie dem Buch von Martin Fowler et al. entnehmen. [Martin Fowler, David Rice, Matthew Foemmel, Patterns of Enterprise Application Architecture, Addison-Wesley Longman, Amsterdam 2003, S. 160. ] Die Vorteile des Active-Record-Musters liegen in der Zentralisierung der Methoden zu einem Objekt. Alle Manipulationsmöglichkeiten eines Modells finden sich direkt am Objekt selbst. In den meisten Implementierungen dieses Entwurfsmusters wird eine gemeinsame Basisklasse für alle Modelle verwendet, welche die gängigsten Methoden, wie das Speichern und Löschen, generisch für alle Daten-Klassen implementiert. Problematisch kann dieser Ansatz an zwei Stellen werden: Zum einen ist es möglich, dass Ihre Modell-Klassen mit wachsender Projektkomplexität in unermessliche und vor allem unwartbare Größen wachsen. Zum anderen stört die Erweiterung einer gemeinsamen Basisklasse die eigentliche Intention der Objektorientierung, möglichst reale Beziehungen zwischen den Objekten zu modellieren, was bei der Ableitung von einer Klasse, die lediglich das Speichern in einer Datenbank implementiert, nicht gegeben ist. ### 7.2.2 Row Data Gateway Einen anderen Ansatz verfolgt hingegen das EntwurfsmusterRow Data Gateway. [Ibid, S. 152 ] In diesem Pattern wird die Trennung der Applikationslogik von der Speicherlogik und der Modell-Klasse selbst empfohlen. Zu jeder Modell-Klasse wird eine sogenannte Finder-Klasse implementiert, die dem Auffinden von Objekten dient. Hier würde dann die Methode getLatestPosts() residieren. Zusätzlich wird empfohlen, für jedes Modell eine sogenannte Gateway-Klasse zu implementieren, welche die eigentliche Speicherlogik implementiert. Auf dieses Gateway greift sowohl die Applikationslogik zu, um die rudimentären Lade- und Speicheroperationen auszuführen, als auch die Finder-Klasse, welche die bereitgestellten Suchmethoden über das Gateway abwickelt. Auch dieser Ansatz hat sowohl Vor- als auch Nachteile: Es wird eine strikte logische Trennung zwischen der Applikationslogik, der Speicherlogik und dem Modell selbst vorgenommen und die objektorientierte Vererbung der Modell-Klassen wird nicht gestört. Allerdings erhält man so mindestens drei Klassen für jedes Modell, was bei komplexeren Vererbungshierarchien mit nur einfachen Zugriffsstrukturen schnell zu einem wahren Wust von Klassen führen kann. ### 7.2.3 Persistent Object Bei dem Begriff Persistent Object handelt es sich nicht um ein bestimmtes Entwurfsmuster, was auch ein Grund war, diesen Namen für die Komponente in eZ Components zu wählen. Der Begriff beschreibt lediglich den Vorgang, wie ein Objekt zur Realisierung von Persistenz zwischen beispielsweise zwei HTTP-Requests gespeichert wird. Die PersistentObject-Komponente zwingt Sie nicht dazu, Ihre Anwendung nach einem bestimmten Muster umzusetzen, sondern überlässt die Entscheidung über geeignete Strukturen komplett Ihnen, je nach Anforderungen Ihres Projekts. Lediglich die benötigten Funktionalitäten wie Laden, Speichern und Suchen werden von der Komponente zentral zur Verfügung gestellt und können beliebig in die Strukturen Ihres Projekts eingebettet werden. Die Erweiterung einer gemeinsamen Basisklasse ist nicht notwendig, ebenso wenig die Implementierung von Zugriffsklassen, wie es das Row-Data-Gateway-Pattern empfiehlt. Im Folgenden werden wir keines der beiden gezeigten Patterns benutzen, sondern lediglich den Zugriff auf PersistentObject direkt aus der Applikationslogik heraus durchführen. Für kleine Projekte ist dieser Ansatz durchaus ausreichend. Die Erfahrung zeigt jedoch, dass auch kleine Projekte schnell umfangreich werden können. Wir empfehlen deshalb, eine für Ihr Projekt geeignete Struktur zur Realisierung der Persistenz zu wählen und diese anhand von PersistentObject zu implementieren. Ob Sie sich dabei für eines der vorgestellten Muster entscheiden, ein anderes Pattern zu Rate ziehen oder eine eigene Idee verwenden, bleibt ganz Ihnen überlassen. ### Ihr Kommentar Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen. >> Zum Feedback-Formular
<< zurück | <top> | vor >>
Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen? Ihre Meinung
Buchempfehlungen
| PHP 5.3 und MySQL 5.1
| Besser PHP programmieren
| Webshops mit Magento
| Sichere Webanwendungen
| PHP 5.3 und MySQL 5.1 - Videotraining
| Apache 2
| Suchmaschinen- Optimierung für Webentwickler
| Joomla! 1.5
Shopping
Versandkostenfrei bestellen in Deutschland und Österreich Info

Copyright © Galileo Press 2008
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

[Galileo Computing]
Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de