Tworzenie warstwy

trwałości danych -

wprowadzenie

Rafał Kasprzyk

Rafał Kasprzyk

Technologie warstwy integracji



Java I/O API



JDBC (ang. Java Database

Connectivity)



SQLJ



JSTL SQL



EJB (ang. Enterprise Java Beans)



JDO (ang. Java Data Objects)



iBATIS SqlMaps



Oracle TopLink



Hibernate



Inne 

Rafał Kasprzyk

Java I/O



Rysunek przedstawia fragment

hierarchii klas umożliwiających

operacje I/O



API zawiera:



Strumienie „połączeniowe”



reprezentują połączenie ze źródłami i

miejscami docelowymi takimi jak pliki lub

gniazda sieciowe



Strumienie „łańcuchowe”



funkcjonują jedynie w połączeniu z

innymi strumieniami



Programowanie operacji I/O opiera

się na korzystaniu z wzorca

Decorator



Możliwość wykonania przydatnej

operacji uzyskujemy dopiero po

połączeniu co najmniej dwóch strumieni,

z których pierwszy obsługuje połączenie,

a drugi udostępnia metody, z których

chcemy skorzystać



Łączenie różnych strumieni

„połączeniowych” i „łańcuchowych”

zapewnia ogromną elastyczność

Rafał Kasprzyk

Serializacja



Mechanizm serializacji

umożliwia utrwalanie i

odczyt obiektów na/z dysku i

po sieci



Serializacja wymusza

wykorzystanie:



Interfejsu Serializable



Strumieni ObjectInputStream

i ObjectOutputStream

Rafał Kasprzyk

Serializacja – przykład



Serializacja

FileOutputStream fos = new FileOutputStream("plik.ser");
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeObject(ob1);
oos.writeObject(ob2);
oos.close();



Deserializacja

FileInputStream fis = new FileInputStream("plik.ser");
ObjectInputStream ois = new ObjectInputStream(fis);
Object ob1 = ois.readObject();
Object ob2 = ois.readObject();
MyClass elf = (Bohater) ob1;
MyClass trol = (Bohater) ob2;
oos.close();

Rafał Kasprzyk

Architektura JDBC



API przeznaczone dla języka Java,

umożliwiające dostęp do większości

systemów bazodanowych

NATIVE

BRIDGE

PURE

MIDDLEWARE

Rafał Kasprzyk

Typy sterowników JDBC



”BRIDGE”

(JDBC-ODBC bridge +

ODBC driver)



Mosty JDBC-ODBC wykorzystują

sterownik ODBC do komunikacji z bazą

danych. Sterownik ODBC musi być

zainstalowany i skonfigurowany na

każdej stacji klienckiej.



”NATIVE”

(Native-API partly-Java

driver)



Program komunikuje się z interfejsem

bazy danych, który musi być

zainstalowany, podobnie jak sterownik

ODBC, na każdej stacji klienckiej.

Rafał Kasprzyk

Typy sterowników JDBC



”MIDDLEWARE”

(JDBC-Net pure Java

driver)



Sterownik JDBC komunikuje się z serwerem

pośredniczącym, za pomocą protokołu

niezależnego od bazy danych. Następnie

serwer tłumaczy polecenia na postać zgodna

z protokołem konkretnej bazy danych.

Rozwiązanie stosowane, gdy konieczny jest

dostęp do baz danych różnych producentów



”PURE”

(Native-protocol pure Java driver)



Sterownik JDBC komunikuje się bezpośrednio

z bazą danych przy pomocy jej protokołu.

Rozwiązanie najczęściej spotykane.

Rafał Kasprzyk

JDBC 1.x



JDBC 1.0 pojawiła się w specyfikacji JDK 1.1



JDBC w tej wersji oferował minimum funkcjonalności.



W pakiecie java.sql znalazły się następujące

interfejsy:



Connection



DatabaseMetaData



Driver



DriverManager,



ResultSet



ResultSetMetaData



Statement



CallableStatement



PreparedStatement



Types

Rafał Kasprzyk

JDBC 2.x



JDBC 2.0 pojawiło się w specyfikacji JDK

1.2



Powstanie związane było z promowaniem

przez Sun nowych technologii:



JTS (ang. Java Transaction Services)



JNDI (ang. Java Naming and Direcory Interface)



JavaBeans, jak również EJB (ang. Enterprise

JavaBeans)



Wprowadzono wiele zmian ułatwiających i

przyśpieszających pracę m.in.:



Przewijane zbiory wyników zapytań (ang.

scrollable ResultSets)



Aktualizacja grupowa danych (ang. batch

updates)



Programowe operacje CRUD



CRUD (ang. Create Read Update Delete)



możliwość zastąpienia języka SQL przez JDBC API (ang.

programmatic inserts/deletes/updates)



Zaawansowane typy danych zgodne z SQL3

(alias SQL99):

BLOB, CLOB, REF, ARRAY, …

Rafał Kasprzyk

JDBC 2.x



JDBC 2.0 podzielony jest na dwa pakiety



JDBC 2.0 core API (client-side API) – zawarty w

pakiecie java.sql – pełen zestaw mechanizmów

dostępu do baz danych



JDBC 1.2 uzupełniony o szereg nowych funkcji.



JDBC 2.0 Optional Package (server-side API) –

zawarty w pakiecie javax.sql – funkcjonalne

uzupełnienie mechanizmów JDBC core API

rozszerzające interfejs strony serwera. Jest

integralną składową platformy J2EE.



Umożliwia korzystanie ze źródeł danych (ang. data

sources) zapewniających funkcje podłączenie do

dowolnej bazy, w tym bazy opartej na plikach, czy

arkuszach Excela



Wprowadzono tzw. zbiory wierszy (ang. RowSets) –

obiektami JavaBeans umożliwiającymi manipulowanie

zbiorem wyników niezależnie od istnienia połączenia z

bazą danych



Dodany został mechanizm puli połączeń

Rafał Kasprzyk

JDBC 3.x



JDBC 3.0 pojawiło się wraz z JDK 1.4:



Zawiera JDBC core API oraz JDBC

Optional Package



Wprowadzono mechanizm konektorów

(ang. connectors) pozwalający w

zunifikowany sposób łączyć się z

różnymi źródłami danych, w tym

systemami EIS (ang. Enterprise

Information System) i bazami

sieciowymi



Trzy implementacje zbioru wierszy:



JDBCRowSet



CachedRowSet



WebRowSet

Rafał Kasprzyk

JDBC 3.x



Pozostałe ważne zmiany wprowadzone w nowej

wersji:



Punkty zapisu (ang. SavePoints), pozwalające na powrót (ang.

rollback) transakcji do określonego momentu



Powtórne użycie prekompilowanych wyrażeń



Konfiguracja puli połączeń



Sposób grupowania źródeł danych i rozmiaru puli



Możliwość wykorzystania metadanych prekompilowanych

wyrażeń



Informacje o liczbie i typie parametrów w takim wyrażeniu



Uzyskiwanie informacji o wartościach w kolumnach, w

których wartości generowane są automatycznie przez bazę

danych np. ROWID



Otwierania wielu zbiorów wyników na jednym połączeniu

JDBC



Nowe typy danych:

BOOLEAN, DATALINK

(referencja do

zewnętrznych danych)



Modyfikowalne typy:

BLOB, CLOB, REF, ARRAY



W przypadku przechowywania w bazie typów strukturalnych

istnieje możliwość skorzystania z metadanych, które będą

zawierały informacje o hierarchii typów

Rafał Kasprzyk

JDBC – przykład



Kolejne etapy obsługi bazy danych przedstawione zostały

na przykładzie lokalnego połączenia z bazą danych

zarządzaną przez ODBC



Zainicjowanie sterownika

Class.forName(”sun.jdbc.odbc.JdbcOdbcDriver”);



Połączenie z bazą danych

Connection connect =

DriverManager.getConnection(jdbc.odbc.TestDB);



Wykonanie polecenia SQL

Statement statement = connect.createStatement();

ResultSet rs =

statement.executeQuery(”select * from Osoba”);



Odbiór i obróbka wyników

String id, imie, nazwisko, wiek, wzrost;

while(rs.next()) {

id = rs.getString(1);

imie = rs.getString(2);

nazwisko = rs.getString(3);

wiek = rs. getString(4);

wzrost = rs.getString(5);

System.out.println(”|”+id+”|”+imie+”|”+nazwisko+

”|”+wiek+”|”+wzrost+”|”);

}



Zamknięcie połączenia z bazą danych

statement.close();

connect.close();

Rafał Kasprzyk

SQLJ



Umożliwia zagnieżdżanie instrukcji SQL w kodzie

Java



Stanowi alternatywę dla bezpośredniego

korzystania z interfejsu JDBC



Pozwala na pisanie bardziej zwartych i czytelniejszych

programów



Zapewnie kontrolę poprawności odwołań do obiektów

baz danych i weryfikację składni instrukcji SQL na etapie

kompilacji



W standardzie SQLJ instrukcje SQL mają charakter

statyczny, co niekiedy jest istotnym ograniczeniem



Istnieją rozszerzenia SQLJ (np. w Oracle9i) wspierające

dynamiczne zapytania



Niestety zupełnie ”martwy standard”

String name = “Jan”;
String surname = “Kowalski”;

#sql {

INSERT INTO User (name, surname)

VALUES (:name, :surname)

};

Rafał Kasprzyk

JSTL SQL



Wygodna biblioteka znaczników wykorzystywana

w prostych aplikacjach opartych na stronach JSP



Wykorzystanie JSTL SQL narusza model MVC

(ang. Model-View-Control)



Warstwę prezentacji zawiera kod związany z logikę

biznesową

…
<sql:query var="Users">
SELECT * FROM User
</sql:query>
<table border="1">

<c:forEach var="columnName" items="${Users.columnNames}">
<th><c:out value="${columnName}"/></th>
</c:forEach>
<c:forEach var="row" items="${Users.rows}">
<tr>
<c:forEach var="column" items="${row}">
<td><c:out value="${column.value}"/></td>
</c:forEach>
</tr>
</c:forEach>

</table>

Rafał Kasprzyk

Rodzaje komponentów EJB



Platforma J2EE wyróżnia trzy rodzaje komponentów

EJB (ang. Enterprise Java Beans):



Session Beans to komponenty realizujące logikę aplikacji.



Stateful Session Bean – przechowują stan dialogu z klientem



Stateless Session Bean – nie przechowują stanu dialogu z

klientem



Entity Beans reprezentują obiekt biznesowy z systemu

przechowywania danych. Komponenty Entity Beans są

współdzielone pomiędzy klientami, a dzięki systemowi

identyfikacji obiektów, kontener nie dopuszcza do

powstania dwóch komponentów reprezentujących te

same dane.



CMP (ang. Container Managed Persistence) – odpowiedzialność za

synchronizację stanu komponentu z bazą danych spoczywa na

kontenerze EJB



BMP (ang. Bean Managed Persistence) – programista musi

zapewnić właściwe odwzorowanie danych z bazy na komponenty

EJB i odwrotnie.



Message-Driven Beans to komponenty implementujące

logikę związaną z reakcją na komunikaty pochodzące z

warstwy pośredniej (ang. Message-Oriented Middleware).

Rafał Kasprzyk

Entity Beans



Każdy encyjny komponent EJB jest oparty o tabelę

w relacyjnej bazie danych, a każda instancja

komponentu encyjnego reprezentuje wiersz w

tabeli



Cechy encyjnych komponentów EJB



Trwałość



Typowo składowane w relacyjnej bazie danych



Odporne na awarie aplikacji, serwera aplikacji, serwera BD



Trwałość zarządzana przez kontener (CMP) lub komponent (BMP)



Współdzielenie



Możliwość współdzielenia instancji komponentu przez kilku

klientów lub korzystanie z różnych instancji reprezentujących te

same dane



Unikalny identyfikator (ang. primary key)



Podstawowe kryterium wyszukiwania obiektów



Związki



Umożliwiają tworzenie powiązań pomiędzy komponentami

encyjnymi



Analogia do związków między tabelami w relacyjnej bazie

danych

Rafał Kasprzyk

CMP



Kontener EJB obsługuje wszystkie

operacje na bazie danych, których

wymaga komponent



Kod komponentu nie zawiera żadnych

instrukcji SQL



Przenaszalność komponentu



Niezależności od schematu bazy i dialektu

SQL wykorzystywanego przez konkretny

serwer bazy danych



Kontener generuje odwołania do bazy

danych w oparciu o abstrakcyjny

schemat podany w deskryptorach

instalacji



Kontener EJB obsługuje również związki

między komponentami encyjnymi

Rafał Kasprzyk

BMP



Programista komponentu dostarcza

kodu zarządzającego trwałością

komponentu



Należy zaimplementować metody do

odczytu, zapisu, manipulacji danymi oraz

zarządzania związkami



ejbLoad(), ejbStore(), ejbCreate(),

ejbPostCreate(), ejbRemove(), ejbFindXXX()



Kod komponentu zawiera wywołania JDBC i

SQLJ



Znacznie ograniczona przenaszalność



Kod odwołuje się do konkretnego schematu

bazy danych



Elastyczność



Twórca komponentu w pełni zarządza jego

trwałością

Rafał Kasprzyk

Tworzenie EJB



Interfejs domowy (Home/LocalHome)



Wykorzystywany przez klientów do tworzenia,

usuwania i wyszukiwania komponentów encyjnych



Interfejs komponentowy (Remote/Local)



Zawiera deklaracje metod biznesowych

komponentu, udostępnianych klientom



Klasa komponentu



Reprezentuje dane biznesowe



Zawiera metody dostępu do danych i manipulacji

danymi



Może zawierać kod walidujący dane



Klasa klucza głównego



Wykorzystywana do identyfikacji instancji

komponentu



Deskryptor instalacji (ang. deployment

descriptor)



Plik XML z danymi konfiguracyjnymi

wykorzystywanymi przez kontener

Rafał Kasprzyk

Wady EJB



Bardzo złożona technologia



Duży nakład pracy konieczny do

stworzenia komponentu i jego

konfiguracji



„failed technology”



Mała elastyczność i wydajność w

zakresie komunikacji z bazą danych



Mało funkcjonalny język zapytań EJB-QL



Nie pozwalają na wykorzystanie

podstawowych zalet obiektowego

podejścia do tworzenia aplikacji



Dziedziczenie



Polimorfizm



…

Rafał Kasprzyk

Wady EJB



Brak możliwości testowania

komponentów EJB poza

środowiskiem kontenera



Trudności w przeprowadzaniu testów

jednostkowych



Trudności w migracji aplikacji

pomiędzy serwerami różnych

producentów związane z

komponentami EJB



Każdy serwer ma własne pliki

konfiguracyjne (ejb-jar.xml)

Rafał Kasprzyk

EJB 3.0 – istotne zmiany



Plik konfiguracyjny ejb-jar.xml nie

jest potrzebny



Cała konfiguracja przeprowadzana jest

z wykorzystaniem mechanizmu

annotations (@Stateless, @Entity,

…)



Znacząco uproszczony sposób

tworzenia



Komponenty nie muszą implementować

żadnych zewnętrznych interfejsów



Aplikacja bazuje na tzw. zwyczajnych,

starych obiektach Java – POJO (ang.

Plain Old Java Objects)

Rafał Kasprzyk

EJB 3.0 – istotne zmiany



Rozbudowany język zapytań EJB-QL



Możliwość wykorzystania zalet

obiektowego podejścia do tworzenia

aplikacji



Dziedziczenie



Polimorfizm



…



Komponenty encyjne mogą być

wykorzystywane poza środowiskiem

serwera aplikacji

Rafał Kasprzyk

JDO



JDO to specyfikacja do utrwalania obiektów Java

stworzona przez Sun, w składnicy danych, którą

możą być



Relacyjny DBMS



Obiektowy DBMS



Pliki XML, pliki tekstowe



JDO ma wiele implementcji



Komercyjne



JDO Genie, JPower Map, JCredo, ObjectDB, XCalia, JORM



Open source



JDO Instruments, JDOMax, Speedo, Jakarta OJB, JPOX



JPOX to darmowa implementacja standardów

JDO 1.0 i JDO2.0



Obecnie prawdopodobnie najbardziej popularna



Wsparcie dla większości relacyjnych DBMS



MySQL, Firebird, Informix, Oracle, Sybase, DB2,

SAPDB/MaxDB



Bardzo dobrze udokumentowana

Rafał Kasprzyk

Klasy JDO



Zdolne do trwałości (ang. persistence

capable)



Klasa, której obiekty mają być utrwalane musi

być ulepszona (ang. JDO enhanced )na

podstawie metadanych.



Dla tych klas muszą istnieć metadane



pliki *.jdo (deskryptory)



Świadome trwałości (ang. persistence

aware)



Klasy manipulujące instancjami klas zdolnych

do trwałości. Klasy te są automatycznie

ulepszane



Zwyczajne (ang. normal)



Klasy nie mające nic wspólnego z JDO. Nie są

opisywane za pomocą metadanych i nie są

ulepszane

Rafał Kasprzyk

Menedżer utrwalania obiektów

Properties props=new Properties();

props.put("javax.jdo.PersistenceManagerFactoryClass",

"org.jpox.PersistenceManagerFactoryImpl");

props.put("javax.jdo.option.ConnectionDriverName",

"com.mysql.jdbc.driver");

props.put("javax.jdo.option.ConnectionURL",

"jdbc:mysql://localhost/jpox");

props.put("javax.jdo.option.ConnectionUserName",

"mysql");

props.put("javax.jdo.option.ConnectionPassword","");

PersistenceManagerFactory

pmf=JDOHelper.getPersistenceManagerFactory(props);

PersistenceManager pm=pmf.getPersistenceManager();



PersistenceManagerFactory



Klasa służąca do uzyskania dostępu do zarządcy

trwałości



Inicjalizacja na poziomie aplikacji (jak w przykładzie)



Inicjalizacja za pomocą pliku properties lub JNDI



PersitenceManager



Klasa odpowiedzialna za utrwalanie obiektów,

odczytywanie trwałych obiektów ze składnicy danych i

usuwanie obiektów

Rafał Kasprzyk

Rodzaje obiektów w JDO

(nomenklatura)

Rafał Kasprzyk

Zapis nowego obiektu do bazy

Transaction tx=pm.currentTransaction();
try {

tx.begin();
Product product = new Product("T20MT",

"A standard mp3 player from iRiver",

99.99);

pm.makePersistent(product);
tx.commit();

}
finally {

if (tx.isActive()) {
tx.rollback();
}

}

Rafał Kasprzyk

Aktualizacja wpisu w bazie

Transaction tx=pm.currentTransaction();

try {

tx.begin();

String product_name = product.getName();

...

product.setPrice(89.99);

tx.commit();

}

finally {

if (tx.isActive()) {

tx.rollback();

}

}

Rafał Kasprzyk

Usunięcie obiektu z bazy

Transaction tx=pm.currentTransaction();

try {

tx.begin();

String product_name = product.getName();

...

pm.deletePersistent(product);

tx.commit();

}

finally {

if (tx.isActive()) {

tx.rollback();

}

}

Rafał Kasprzyk

Modyfikacja obiektu poza

transakcją



Działanie na obiekcie poza

transakcją pozwala dowolnie

modyfikować obiekt bez

jakichkolwiek zmian w bazie danych.

W tym celu należy:



Przenieść obiekt w stan Transient



makeTransient()



Odłączyć obiekt



detachCopy()



Wykorzystać poza transakcyjne

czytanie/pisanie



nonTransactional[Read/Write]()

Rafał Kasprzyk

Wczytanie obiektu z bazy



Wykorzystanie tożsamości obiektu

Object identity = pm.getObjectId(obj);
Object obj = pm.getObjectById(identity);



Użycie JDOQL (ang. JDO Query Language)

Query query = pm.newQuery(Product.class,

„price < value");

query.declareParameters(„float value");
List results = query.execute(100);
Iterator iter = results.iterator();
while (iter.hasNext())
{

Product product = (Product)iter.next();
…

}



Extent jako brutalna alternatywa dla

JDOQL

Extent e = pm.getExtent(Product.class, true);

Rafał Kasprzyk

JDO - metadane

package pl.isolution.jdo

public class Product {

String pname;

String description;

float price;

…

}

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE jdo PUBLIC

"-//Sun Microsystems, Inc.//DTD Java Data Objects Metadata

2.0//EN"

"http://java.sun.com/dtd/jdo_2_0.dtd">

<jdo>

<package name="pl.isolution.jdo">

<class name= "Product" identity-type="datastore">

<field name= "pname"/>

<field name= "description"/>

<field name= "price"/>

</class>

</package>

</jdo>

Rafał Kasprzyk

Zalety JDO



Można zmienić silnik bazy danych, a

nawet typ bazy bez zmian w kodzie



Nie trzeba tworzyć struktury bazy

danych od nowa



Możliwość wykorzystania istniejącego

schematu



Możliwość automatycznej generacji

schematu



Koniec z normalizacją ;)



Klasy trwałe nie musza implementować

żadnych specjalnych interfejsów



Aplikacja bazuje na tzw. zwyczajnych,

starych obiektach Java – POJO (ang. Plain

Old Java Objects)

Rafał Kasprzyk

iBATIS SqlMaps



Biblioteka zapewniająca niewątpliwe

korzyści jakie daje zastosowanie

mechanizmu odwzorowań obiektowo-

relacyjnych, a jednocześnie



Zmniejsza zagrożenia związane z ich

nieuzasadnionym stosowaniem



Nie zmusza do stosowania rozwiązań

znacznie wykraczających poza potrzeby



Biblioteka należy do klasy tzw. lekkich

ORM’ów



Świetna współpraca ze Spring

Framework



Spring to obecnie prawdopodobnie

najpopularniejsze środowiskiem rozwoju

aplikacji J2EE

Rafał Kasprzyk

Person.java Person.sql

package domain;

public class Person {

private int id;

private String firstName;

private String lastName;

private Date birthDate;

private double weight;

private double height;

public int getId () {

return id;

}

public void setId (int id) {

this.id = id;

}

…

}

CREATE TABLE PERSON(

ID

NUMBER (5, 0) NOT NULL,

FIRST_NAME

VARCHAR (40) NOT NULL,

LAST_NAME

VARCHAR (40) NOT NULL,

BIRTH_DATE

DATETIME ,

WEIGHT

NUMBER (4, 2) NOT NULL,

HEIGHT

NUMBER (4, 2) NOT NULL,

PRIMARY KEY (ID)

)

Rafał Kasprzyk

sqlMap-config.[xml/properties]

<?xml version="1.0" encoding="UTF-8" ?>

<!DOCTYPE sqlMapConfig

PUBLIC "-//iBATIS.com//DTD SQL Map Config 2.0//EN"

"http://www.ibatis.com/dtd/sql-map-config-2.dtd">

<sqlMapConfig>

<properties resource="sqlmap/maps/SqlMapConfig.properties" />

<settings

cacheModelsEnabled="true"

enhancementEnabled="true"

lazyLoadingEnabled="true"

maxRequests="32"

maxSessions="10"

maxTransactions="5"

useStatementNamespaces="false" />

<typeAlias alias="order" type="domain.Order"/>

<transactionManager type="JDBC" >

<dataSource type="SIMPLE">

<property name="JDBC.Driver" value="${driver}"/>

<property name="JDBC.ConnectionURL" value="${url}"/>

<property name="JDBC.Username" value="${username}"/>

<property name="JDBC.Password" value="${password}"/>

</dataSource>

</transactionManager>

<sqlMap resource="examples/sqlmap/maps/Person.xml" />

</sqlMapConfig>

driver = com.mysql.jdbc.Driver

url = jdbc:mysql://localhost/testDB

username = smith

password = 3w$#kr8u

Rafał Kasprzyk

Person.xml

<?xml version="1.0" encoding="UTF-8" ?>

<!DOCTYPE sqlMap

PUBLIC "-//iBATIS.com//DTD SQL Map 2.0//EN"

"http://www.ibatis.com/dtd/sql-map-2.dtd">

<sqlMap namespace="Person">

<select id="getPerson" parameterClass=”int”

resultClass="domain.Person">

SELECT ID as id, FIRST_NAME as firstName, LAST_NAME as

lastName,

BIRTH_DATE as birthDate, WEIGHT as weight, HEIGHT

as height FROM

PERSON WHERE ID = #value#

</select>

<insert id="insertPerson" parameterClass="domain.Person">

INSERT INTO PERSON (ID, FIRST_NAME, LAST_NAME,

BIRTH_DATE, WEIGHT, HEIGHT) VALUES (#id#, #firstName#,

#lastName#, #birthDate#, #weight#, #height#)

</insert>

<update id="updatePerson" parameterClass="domain.Person">

UPDATE PERSON SET FIRST_NAME = #firstName#, LAST_NAME =

#lastName#, BIRTH_DATE = #birthDate#, WEIGHT = #weight#,

HEIGHT = #height# WHERE ID = #id#

</update>

<delete id="deletePerson" parameterClass="domain.Person">

DELETE PERSON WHERE ID = #id#

</delete>

</sqlMap>

Rafał Kasprzyk

MyAppSqlConfig.java

public MyAppSqlConfig {

private static final SqlMapClient sqlMap;

static {

try {

String resource =

"sqlmap/maps/sqlMap-config.xml ";

Reader reader =

Resources.getResourceAsReader(resource);

sqlMap =

SqlMapClientBuilder.buildSqlMapClient(reader);

}catch (Exception e) {

e.printStackTrace();

}

}

public static getSqlMapInstance () {

return sqlMap;

}

}

Rafał Kasprzyk

Przykład wykorzystania iBATIS

…

SqlMapClient sqlMap = MyAppSqlMapConfig.getSqlMapInstance();

…

Integer personPk = new Integer(5);

Person person =

(Person) sqlMap.queryForObject (“getPerson”, personPk);

…

person.setHeight(1.83);

person.setWeight(86.36);

…

sqlMap.update(“updatePerson”, person);

…

sqlMap.delete (“deletePerson”, person);

…

Person nPerson = new Person();

nPerson.setId(11);

nPerson.setFirstName(“Jan”);

nPerson.setLastName(“Kowalski”);

nPerson.setBirthDate (null);

nPerson.setHeight(1.83);

nPerson.setWeight(86.36);

…

sqlMap.insert (“insertPerson”, nPerson);

…

Rafał Kasprzyk

Zalety iBATIS SQLMaps



iBATIS SQLMaps pozwala



Kojarzyć kolumny i polecenia SQL ze

słowami kluczowymi



Korzystać z pełnych możliwości SQL

bez uciążliwości stosowania JDBC



Usunąć wszelkie polecenia SQL z kodu

aplikacji



Klasy trwałe nie musza

implementować żadnych

specjalnych interfejsów



Aplikacja bazuje na tzw. zwyczajnych,

starych obiektach Java – POJO (ang.

Plain Old Java Objects)

Rafał Kasprzyk

Oracle TopLink



Kolejna ciekawa technologia warstwy

integracji oparta na idei mapowania

obiektowo-relacyjnego



Wykorzystywana w aplikacjach pisanych

w języku Java i opartych o relacyjne

bazy danych



Zasada działania podobna do innych

bibliotek opartych na idei ORM



Programista definiuje w języku XML

zasady odwzorowań obiektów Java na

tabele w relacyjnej bazie danych

(metadane)



TopLink został włączony do systemu

zarządzania bazą danych Oralce9i

Rafał Kasprzyk

Rozwój aplikacji w oparciu o

TopLink



Projektowanie modelu danych dla relacyjnej

bazy danych i jego implementacja w wybranym

RDBMS



Projektowanie obiektowego modelu danych i

jego implementacja w języku Java



Definiowanie metadanych



Implementacja kodu przetwarzania danych w

języku Java



Wykorzystane narzędzia



JDeveloper 10g R3



Zawiera kreatory i edytory odwzorowań



TopLink Workbench



Samodzielna aplikacja ułatwiająca definiowanie odwzorowań



Jedynie biblioteka TopLink API



Brak wsparcia do automatyzacji definiowania odwzorowań

Rafał Kasprzyk

TopLink – podstawowe pojęcia



Deskryptor (ang. descriptor)



Opisuje powiązanie pomiędzy klasą

Javy, a tabelą w relacyjnej bazie

danych



Odwzorowanie (ang. mappings)



Opisuje powiązanie pomiędzy

atrybutem klasy, a kolumną tabeli



Projekt (ang. project)



Gromadzi wszystkie deskryptory i

odwzorowania dla całej aplikacji

Rafał Kasprzyk

Podsumowanie



Technologie warstwy integracji



Wykorzystania SQL na JDBC vs. SQLJ



SQL w warstwie prezentacji – JSTL



EJB – wady i zalety



Wykorzystanie mapowania ORM



EJB



JDO



iBATIS SQLMaps



Oracle TopLink



Hibernate – to dopiero przed nami ;)