Javabasierte Webtechnologien Objektrelationales Mapper und JDO

Javabasierte Webtechnologien

Objektrelationales Mapper und JDO

17.06.2004 Lars Kägebein 2

Überblick

• Motivation• Objektrelationale Mapper - Überblick - Beispiel Hibernate - Performance - Fazit• Java Data Objekt - Überblick - JDO API - Vom normalem Objekt zu einem JDO - Fazit


Motivation

• Lösen des Impendance Mismatch Problems - Objektorientierte Lösungen in komplexen Anwendungen - Zur Speicherung meistens Relationale Datenbanken - unterschiedliche Paradigmen - ziel : Vorteil von beiden vereinen• Probleme - Objektidentität vs Primärschlüssel - Kompositionsmodell vs Fremdschlüssel - Vererbungsmodel vs ? - Verschiedene Datentypen


Überblick O/R Mapper

• Kleiner Projekte eventuell selbst lösen - Sql statments über jdbc / resultSet umwandeln in Datenobjekte

• Bei komplexen Anwendungen mapper nutzen - Automatische Generierung von Datenklassen - Performanceoptimierung möglich die den Overhead durch das Mapping ausgleicht - Unabhänigkeit von verschiedenen Datenbank Herstellern - Cayenne , Jakarta OJB , TopLink , Hibernate


O/R Mapper Hibernate

• Warum Hibernate - Open Source (LGPL) - Populär (circa 16.000 downloads / Monat) - Unterstützung aller großen Datenbanken z.b. mySql , PostgreSql, Oracle , DB2 … - Besitzt Optimierungmöglichkeiten wie Caching, Connection-pooling - Möglichkeit zur Nutzung unterschiedlicher Entwicklungsszenarien - Generierung von java klassen wenn DB Schemata vorhanden und umgekehrt - verschiedene Anfragesprachen (hql, sql, criteria Queries) - Ausführliches logging durch log4j


Funktionsweise von Hibernate

• Genereller Aufbau- Hibernate.properties für

Datenbank und Optimierungsparameter

- Für jede Tabelle in der DB eine .java und eine .hbm.xml

- .java beschreibt die Tabelle selber als Objekt

- .hbm.xml enthält Datentypen mapping und zusätzliche Parameter


Arbeiten mit Hibernate

• Java Datei

hbm.xml Datei


Zusammenspiel zwischen der Datenbank und Hibernate

• Ablauf im Detail- Zugriff nur über die

Datenobjekte die aus der Session kommen (selection) oder in die Session gehen (insert)

- Session von SessionFactory generiert , dort auch Optimierungen umgesetzt

- Zugriff auf Datenbank erfolgt intern durch JDBC oder ähnliches


Anfragen am Beispiel• Erstellen und beenden einer Session

• Eintrag in die Datenbank

• keinerlei Sql !• nur setter Methoden oder mit Konstruktoren arbeiten für inserts!


Anfragen am Beispiel• Verschiedene Abfragen

-HQL als Objektorientierte Erweiterung von SQL - versteht Vererbung, Polymorphie und Assoziationen

-Direkte Abfrage über Criteria - kein sql notwendig


Tools und Performance

• Performance• Sehr abhängig von den Einstellungen und der

Anwendung (Cache Zuweisungen für Querys) • Schlechte Erfahrungen im Zusammenspiel mit Tomcat

• Tools• Kein erstellen der java bzw. xml Dateien notwendig

wenn db-schemata schon vorhanden• Hibernate-extensions beinhaltet folgende Tools : - class2hbm, ddl2hbm, hbm2java - dadurch alle Szenarien abgedeckt


Fazit

• Zwar gewisser Aufwand nötig zur Einarbeitung jedoch danach sehr unabhängig von der Datenbank

• Entwickler muss nicht wissen wie DB Schemata aufgebaut , sämtliche Möglichkeiten ergeben sich durch die Get und Set Methoden

• Durch Criteria keine Kenntnisse von Sql nötig

• Nachteil jedoch eventuell Langsamer • wenn DB Schema sich ändert muss alles geändert

werden• Kein genereller Standard , unterstützt „nur“

Datenbanken (keine anderen Formate)


JDO Einführung

• JDO = Java Data Objects• Standard (API) zur persistenten Speicherung von Java

Objekten• Stellt Interfaces zur Verfügung welche dann von der

jeweiligen Implementierung auf den Datenspeicher zugeschnitten sind

• Dadurch Anwendung unabhängig vom Speicherort seiner Objekte / Daten, xml-files genauso möglich wie verschiedenste Datenbanken

• Soll Objektorientierte Sichtweise auf Daten ermöglichen und Anwendung vom Prozess der Persistierung komplett befreien


JDO API Bestandteile (1)

•JDOHelper für statische Hilfsmethoden und zur Erzeugung der PMF , zusätzlich noch Methoden zum ermitteln des Zustandes bestimmter JDO Objekte


JDO API Bestandteile (2)

• PMF fordert einzelne Instanzen des PM an die darüber konfiguriert werden können

• Parameter zur Optimierung möglich wie Transaktionstrategie und Cachesematik einstellungen

• Angabe der Datasource

• PM verwaltet JDO-Objekte die dort angelegt,gesucht und gelöscht werden können

• Jeder PM hat exklusiven Objektcache und genau einen Transaktionskontex zwecks transaktionaler Absicherung

• Query-Interface dient zur Absetzung von Suchanfragen• sind in JDO-Query Language formuliert


Vom Objekt zu JDO Objekt (1)

• Leicht zu Erreichen und Stärke von JDO • Angabe von den persistenten Eigenschaften von allen

Klassen im Package der Anwendung in XML Metadatei• Mögliche persistence-modifier hierbei : - none , transactional, persistent• Persitente Attribute : erfordern

Speichermediumabgleich ,unterliegen Transaktionsgrenzen• Transactionale Attribute : unterliegen Transaktionsgrenzen• None : sonstige• Persistent und Transactional müßen von JDO Implemtierung

beachtet werden


Vom Objekt zu JDO Objekt (2)

• Code Enhancer erweitert automatisch den .class Bytecode der Normalen Klasse um JDO Erweiterung

• Je nach Definition in der Meta Datei klasse nun :• Persistent Capable , muss auf jeden Fall erweitert werden• Persistent Aware , klasse selber hat keine persistenten

Attribute greift aber auf welche zu (Vererbung etc)• Sonstiges muss nicht vom Enhancer betrachtet werden

• Vorteil : sehr schnelle Erweiterung vorhandener Objekte• Nachteil : inwiefern widersprechen Veränderungen im

ByteCode der Java Grundidee der Unabhängigkeit ?


Identität von JDO Objekten• In Java Anwendungen von == bestimmt (gleicher

Speicherbereich innerhalb der JVM)• Bei JDO nicht sicher da Objekt von Anwendung oder

Speichermedium kommen kann !• Je nach Design der Anwendung : • Application Identity , dabei Verwaltet die Anwendung die

Datenobjekte durch hinzufügen von Objekt-Id klasse zur eigentlichen klasse

• Sinnvoll für hoch portable Klassen für verschiedene Anwendungen , nutzbar über verschiedene JDO Implementationen hinweg

• Datastore Identity , hier verwaltet eine Objekt id Klasse alle Objekte die aus der Speicherquelle kommen und garantiert dadurch Identität (nicht sichtbar)


JDO Objektzustände

• Können über JDOHelper abgefragt werden- Mögliche zustände hierbei : - Persistent (im Speichermedium)- transactional (mit Transaktion verbunden)- dirty (geändert in der Transaktion)- new (während der Transaktion persitent geworden)- deleted (innerhalb der Transaktion gelöscht)• Stellt im Prinzip die Eigenschaften dar die in der Meta Datei

festgelegt wurden• Dient zur internen Verwaltung der Transaktionen in JDO


Anfragesprache JDO-QL

• Ziel ist es ein Objekt zurückzuliefern oder eine Collection über die dann per Get Methoden die Werte ausgelesen werden können

• WHERE deklaration durch Filter abgebildet• Keine Like Operatoren sondern startWith() und endsWith()

Anwendung auf das Ergebnis Objekt


Fazit

• Vorteile• Performanceeinschätzungen schlecht möglich da sehr

stark abhängig von JDO Implementierung• Dadurch das als Standart definiert verschiedenste

Implementierungen denkbar• Sehr schnelle Erreichbarkeit von Objektpersistenz• Anwendungen können ihr Speichermedium schnell

ändern ,doppelte Verwendung von JDO Objekten denkbar z.b. online / offline Umgebungen

• Nachteile• Inwiefern widersprechen Veränderungen im ByteCode der

Java Grundidee der Unabhängigkeit ?• Anfragesprache (noch) nicht sehr mächtig , soll aber in der

Zukunft erweitert werden


Quellen

• www.hibernate.org

• www.jdocentral.com

• Studienarbeit Tobias Vogel

• Artikel : Freie Sicht auf Daten (Javamagazin 06/04)

http://www.hibernate.org/

http://www.jdocentral.com/


Fragen ?

Vielen Dank für IhreAufmerksamkeit

Documents

Javabasierte Webtechnologien Objektrelationales Mapper und JDO