Herzlich Willkommen… welcome… soyez la bienvenue…

Name:Frank Dillinger Studium:Angewandte Informatik / Wirtschaft Fachhochschule Kaiserslautern (2000 – 2004) Arbeitgeber:INTRASOFT International S.A EUROPEAN Parliament (Luxembourg) DG INNOVATION AND TECHNOLOGICAL SUPPORT Position:Software Architect Technologien:Java, J EE, Spring, Spring MVC, Hibernate, Maven 2…

Gegenüberstellung zweier Softwarearchitektur - Ansätze unter Verwendung eines Objekt Relationalen Mappers (ORM) wie JPA, Hibernate oder EJB….

Multi Tier / Layer Software Architektur Client Layer (FAT Client, Web Client, (Web)Service..) Business Layer Data Access Layer DATABASE Wie wird die Kommunikation zwischen den Layern realisiert? Welche Objekte werden für die Kommunikation verwendet? ? ?

Business Layer Client Layer Data Transport Object (DTO) Domain Model Object Data Transport Objekte und Kapselung der Persistenz Objekte Jeder Layer verwendet sein eigenes Objekt Persistenz Objekte (PO) nur im Data Access Layer sichtbar. Business Layer verwendet Domain Model. Kommunikation zum Client wird über Data Transport Objekte (DTO)realisiert. Vorteile: Vollständig initialisierte Objekt-Graphen Persistenz Informationen z.B. JPA Annotations nicht in Domain Model sichtbar. Nachteile: aufwändiger zu realisieren Mapping zwischen DTO Domain Model PO muss implementiert und gepflegt werden Data Access Layer Persistence Object (PO) DATABASE Persistence - Framework (OR – Mapper)

Business Layer Client Layer Domain Model Object (POJO) Domain Model Objekt als Transport- und Persistenzobjekt Alle Layer verwenden das Domain Model (POJO) (Plain Old Java Object) Nachteile: Lazy Loading Problematik, wenn Objekt nicht mehr mit dem Persistenz-Framework verbunden ist (Detached Object). Persistenz Informationen z.B. JPA Annotations in Domain Model sichtbar. Vorteile: Kein Mapping (Assembling) zwischen Layern notwendig Domain Model Objekt kann mit Konfiguration (Hibernate Mapping File) oder Annotations (JPA) zu einem Persistenzobjekt gemacht werden) Data Access Layer DATABASE Persistence– Framework (OR Mapper)

7 Anwendung eines Object-Relationalen-Mapping (ORM) Persistenz - Frameworks Ein ORM Framework ermöglicht es (Java) Objekte persistent in einer Relationalen Datenbank abzuspeichern und aus Entities einer Relationalen Datenbank wieder (Java) Objekte zu erstellen. Das Mappen zwischen Objekten und Datenbanktabellen erfolgt mittels META Daten in Form von Annotations (JPA) oder Mapping Files (Hibernate). Das ORM Framework hat Optimierungsfunktionen wie Caching und Lazy Loading integriert. Relational Database Table META Data Java Object Persistence – Framework (OR Mapper)

Audio Book Klassendiagramm:

9 Beispiel: Lazy Laoding

10 Ausdehnung des Persistenz-Frameworks Client Layer Business Layer Domain Model Object (POJO) Data Access Layer Persistence – Framework (OR Mapper) DATABASE session-per-request with detached objects / POJO Façade Open-session-in-view (OSIV) Wo beginnt das ORM Persistenz-Framework ??

Persistenz-Framework bis in den Business Layer ausgedehnt (session-per-request with detached objects / POJO Facade) Client Layer Business Layer Data Access Layer Persistence – Framework (OR Mapper) DATABASE In diesem Ansatz ist das Domain Model Objekt (POJO) nur eine bestimmte Zeit mit dem Persistenz- Framework verbunden. Außerhalb des Persistenz- Frameworks ist Lazy Loading nicht möglich! (Detached Object) Das Domain Model Objekt (POJO) kann wieder mit Persistenz-Framework (Kontext) verbunden werden. (Re-Attached Object) Domain Model Object (POJO) Domain Model Object (POJO) 1.Lazy Loading 2.Fehlende Assoziationen / Objekt-Graph nicht initialisiert 3.Unterscheidung der Vollständigkeit der Objekte (Full / Light Loading)

Client Layer Business Layer Data Access Layer OR Mapper DATABASE Domain Model Object (POJO) 1. Lazy Loading Um eine Lazy Loading Exception zu vermeiden, ist lediglich ein implizites Nachladen / fetchen der Assoziation innerhalb des Persistenz-Frameworks (OR Mapper) notwendig. <class name="de.fd.mediamanager.model.audiobook.AudioBook" table="AUDIO_BOOK" schema="media manager" lazy="true"> <class name="de.fd.mediamanager.model.audiobook.AudioBook" table="AUDIO_BOOK" schema="media manager" lazy= "false">

1.1 Lazy Loading Laden des Audio Books ohne Assoziationen auf Server Seite (Data Access Layer)Laden des Audio Books mit Assoziationen auf Server Seite (Data Access Layer)Laden des Audio Books im Controller (außerhalb des Persistenz – Frameworks, Client Layer)

Unter bestimmten Umständen kann es sein, dass eine Assoziation nicht vorhanden ist, also null ist! Daraus ergibt sich die Frage: Soll / Muss der Objekt – Graph (immer) inizialisiert werden ??? Client Layer Business Layer Data Access Layer Persistence - Framework DATABASE Domain Model Object (POJO) 2.Fehlende Assoziationen / Objekt - Graph nicht initialisiert…

Client Layer Business Layer Data Access Layer OR Mapper DATABASE Domain Model Object (POJO) 2.1 Fehlende Assoziationen / Objekt-Graph nicht initialisiert… Beispiel: Die Kontaktdatenpflege

Client Layer Business Layer Data Access Layer OR Mapper DATABASE Domain Model Object (POJO) 2.2 Fehlende Assoziationen / Objekt - Graph nicht initialisiert… Bevor das Domain Objekt (POJO) das Persistenz–Framework verlässt, kann es sinnvoll sein, es für den Aufenthalt außerhalb des Persistenz–Frameworks zu präparieren. Das Präparieren des POJOs könnte mit Hilfe der Methoden detachObject(AudioBook) und reAttachObject(AudioBook) erfolgen.

2.3 Die Methode detachObject (...) in der Facade... (Business Layer) Die Methode detachObject(..) überprüft den Objekt – Graphen ab dem Startpunkt und erzeugt gegebenenfalls die Assoziationen um den Objekt – Graphen zu komplettieren. Die Werte der Attribute in den Assoziationen werden nicht initialisiert !

2.3 Die Methode reAttachObject (...) in der Facade... (Business Layer) Die Methode reAttachObject(..) beginnt am Ende des Objekt – Graphen die Überprüfung ob die vorhandenen Assoziationen (POJO Objekte) leer sind. Ist ein Objekt leer wird es durch null ersetzt. Somit wird der Objekt – Graph rückwärts überprüft und jedes leere Objekt durchnull ersetzt. Damit dies funktioniert, muss jedes POJO Objekt die MethodeisEmpty() implementieren, da jedes POJO individuell entscheiden muss, ob es leer ist oder nicht. Die Methode reAttachObject (..) ist die Umkehrung von detachObjekt(..)

19 Client Layer Business Layer Data Access Layer Persistence - Framework DATABASE Domain Model Object (POJO) 2.4 Sonar….

Client Layer Business Layer Data Access Layer OR Mapper DATABASE Domain Model Object (POJO) 3. Unterscheidung der Vollständigkeit der Objekte (Full / Light Loading) Getter Funktionen in der Facade (Business Layer)!

21 Business Layer Client Layer Data Transport Object (DTO) Domain Model Object DATABASE Client Layer Business Layer Data Access Layer Persistence – Framework (OR Mapper) DATABASE Domain Model Object (POJO) Data Transport Objekt versus Domain Model (POJO) Data Access Layer Persistence Object (PO) Persistence – Framework (OR Mapper)

22 Vielen Dank für Ihre Aufmerksamkeit…