Javabasierte Webtechnologien Objektrelationales Mapper und JDO

Lars Kägebein2 Überblick Motivation Objektrelationale Mapper - Überblick - Beispiel Hibernate - Performance - Fazit Java Data Objekt - Überblick - JDO API - Vom normalem Objekt zu einem JDO - Fazit

Lars Kägebein3 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

Lars Kägebein4 Ü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

Lars Kägebein5 O/R Mapper Hibernate Warum Hibernate - Open Source (LGPL) - Populär (circa 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

Lars Kägebein6 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

Lars Kägebein7 Arbeiten mit Hibernate Java Datei  hbm.xml Datei

Lars Kägebein8 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

Lars Kägebein9 Anfragen am Beispiel Erstellen und beenden einer Session Eintrag in die Datenbank keinerlei Sql ! nur setter Methoden oder mit Konstruktoren arbeiten für inserts!

Lars Kägebein10 Anfragen am Beispiel Verschiedene Abfragen -HQL als Objektorientierte Erweiterung von SQL - versteht Vererbung, Polymorphie und Assoziationen -Direkte Abfrage über Criteria - kein sql notwendig

Lars Kägebein11 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

Lars Kägebein12 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)

Lars Kägebein13 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

Lars Kägebein14 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

Lars Kägebein15 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

Lars Kägebein16 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

Lars Kägebein17 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 ?

Lars Kägebein18 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)

Lars Kägebein19 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

Lars Kägebein20 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

Lars Kägebein21 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

Lars Kägebein22 Quellen Studienarbeit Tobias Vogel Artikel : Freie Sicht auf Daten (Javamagazin 06/04)

Lars Kägebein23 Fragen ? Vielen Dank für Ihre Aufmerksamkeit