Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00222 007388 11068525 na godz. na dobę w sumie
Java. Aplikacje bazodanowe. Najlepsze rozwiązania - książka
Java. Aplikacje bazodanowe. Najlepsze rozwiązania - książka
Autor: Liczba stron: 296
Wydawca: Helion Język publikacji: polski
ISBN: 83-7361-260-2 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> java - programowanie
Porównaj ceny (książka, ebook, audiobook).

Aplikacje biznesowe dotyczą danych -- niezależnie od tego, czy są to dane o produkcie, szczegóły dotyczące kart kredytowych użytkowników czy preferowanego koloru kupowanych samochodów. Wraz ze wzrostem znaczenia informacji wzrosła także złożoność dostępu do nich. Programiści Javy mogą wybierać teraz spośród różnego rodzaju interfejsów API i technologii -- EJB, JDO, JDBC, SQL, RDBMS, OODBMS i innych. Do tej pory byli oni zdani na siebie przy podejmowaniu decyzji o tym, który model najlepiej pasuje do ich aplikacji i jak w najlepszy sposób korzystać z wybranego API.

Książka 'Java. Aplikacje bazodanowe. Najlepsze rozwiązania' przychodzi z pomocą programistom. Teraz nie muszą już oni przeszukiwać kilku książek na temat różnych API, aby zdecydować o odpowiedniej metodzie. Ten obszerny przewodnik omawia podstawy wszystkich wiodących interfejsów API (Enterprise JavaBeans, Java Data Objects, JDBC, a także innych, mniej znanych opcji), objaśnia metodologię i komponenty projektowe wykorzystujące wspomniane interfejsy oraz prezentuje rozwiązania najbardziej dostosowane do różnych typów aplikacji.

Książka omawia także zagadnienia dotyczące projektowania baz danych, począwszy od architektury tabel, skończywszy na normalizacji. Autor przedstawia najlepsze rozwiązania rozmaitych problemów. Nauczysz się w jaki sposób przeprowadzać różne rodzaje normalizacji, a także dowiesz się, kiedy warto przeprowadzić denormalizację. Uzyskasz także szczegółowe instrukcje dotyczące optymalizacji zapytań SQL w celu najlepszego wykorzystania struktury bazy danych. Zaprezentowano także praktyczne zastosowania omawianych technik dostarczając informacje, które Czytelnik może zastosować natychmiast we własnych projektach aplikacji biznesowych.

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

IDZ DO IDZ DO PRZYK£ADOWY ROZDZIA£ PRZYK£ADOWY ROZDZIA£ SPIS TREĎCI SPIS TREĎCI KATALOG KSI¥¯EK KATALOG KSI¥¯EK KATALOG ONLINE KATALOG ONLINE ZAMÓW DRUKOWANY KATALOG ZAMÓW DRUKOWANY KATALOG TWÓJ KOSZYK TWÓJ KOSZYK DODAJ DO KOSZYKA DODAJ DO KOSZYKA CENNIK I INFORMACJE CENNIK I INFORMACJE ZAMÓW INFORMACJE ZAMÓW INFORMACJE O NOWOĎCIACH O NOWOĎCIACH ZAMÓW CENNIK ZAMÓW CENNIK CZYTELNIA CZYTELNIA FRAGMENTY KSI¥¯EK ONLINE FRAGMENTY KSI¥¯EK ONLINE Wydawnictwo Helion ul. Chopina 6 44-100 Gliwice tel. (32)230-98-63 e-mail: helion@helion.pl Java. Aplikacje bazodanowe. Najlepsze rozwi¹zania Autor: George Reese T³umaczenie: Rados³aw Meryk ISBN: 83-7361-260-2 Tytu³ orygina³u: Java Database Best Practices Format: B5, stron: 296 Przyk³ady na ftp: 54 kB Aplikacje biznesowe dotycz¹ danych — niezale¿nie od tego, czy s¹ to dane o produkcie, szczegó³y dotycz¹ce kart kredytowych u¿ytkowników czy preferowanego koloru kupowanych samochodów. Wraz ze wzrostem znaczenia informacji wzros³a tak¿e z³o¿onoġæ dostêpu do nich. Programiġci Javy mog¹ wybieraæ teraz spoġród ró¿nego rodzaju interfejsów API i technologii — EJB, JDO, JDBC, SQL, RDBMS, OODBMS i innych. Do tej pory byli oni zdani na siebie przy podejmowaniu decyzji o tym, który model najlepiej pasuje do ich aplikacji i jak w najlepszy sposób korzystaæ z wybranego API. Ksi¹¿ka „Java. Aplikacje bazodanowe. Najlepsze rozwi¹zania” przychodzi z pomoc¹ programistom. Teraz nie musz¹ ju¿ oni przeszukiwaæ kilku ksi¹¿ek na temat ró¿nych API, aby zdecydowaæ o odpowiedniej metodzie. Ten obszerny przewodnik omawia podstawy wszystkich wiod¹cych interfejsów API (Enterprise JavaBeans, Java Data Objects, JDBC, a tak¿e innych, mniej znanych opcji), objaġnia metodologiê i komponenty projektowe wykorzystuj¹ce wspomniane interfejsy oraz prezentuje rozwi¹zania najbardziej dostosowane do ró¿nych typów aplikacji. Ksi¹¿ka omawia tak¿e zagadnienia dotycz¹ce projektowania baz danych, pocz¹wszy od architektury tabel, skoñczywszy na normalizacji. Autor przedstawia najlepsze rozwi¹zania rozmaitych problemów. Nauczysz siê w jaki sposób przeprowadzaæ ró¿ne rodzaje normalizacji, a tak¿e dowiesz siê, kiedy warto przeprowadziæ denormalizacjê. Uzyskasz tak¿e szczegó³owe instrukcje dotycz¹ce optymalizacji zapytañ SQL w celu najlepszego wykorzystania struktury bazy danych. Zaprezentowano tak¿e praktyczne zastosowania omawianych technik dostarczaj¹c informacje, które Czytelnik mo¿e zastosowaæ natychmiast we w³asnych projektach aplikacji biznesowych. 5RKUVTGħEK Przedmowa ........................................................................................................................9 Część I Architektura danych ...................................................c...............15 Rozdział 1. Elementy aplikacji bazodanowej ...........................................................17 Rodzaje architektury aplikacji bazodanowych ...................................................c..............................18 Modele komponentów...................................................c...................................................c....................33 Modele trwałości...................................................c...................................................c..............................35 Rozdział 2. Architektura danych relacyjnych ...........................................................37 Pojęcia relacyjne ...................................................c...................................................c...............................38 Modelowanie ...................................................c...................................................c....................................49 Normalizacja...................................................c...................................................c.....................................51 Denormalizacja...................................................c...................................................c.................................61 Odwzorowanie obiektowo-relacyjne...................................................c...............................................65 Rozdział 3. Zarządzanie transakcjami.......................................................................71 Transakcje ...................................................c...................................................c.........................................72 Współbieżność...................................................c...................................................c..................................76 Zarządzanie transakcjami w JDBC ...................................................c..................................................80 Paradygmaty dotyczące zarządzania transakcjami ...................................................c......................88 Część II Modele trwałości ...................................................c...................91 Rozdział 4. Podstawowe pojęcia związane z trwałością......................................93 Wzorce trwałości...................................................c...................................................c..............................93 Aplikacja „księga gości” ...................................................c...................................................c.................98 6 Spis treści Rozdział 5. EJB CMP — trwałość zarządzana przez kontener EJB..................115 Który model CMP zastosować?...................................................c......................................................116 Model CMP EJB 1.0 ...................................................c...................................................c.......................117 Model CMP wersji EJB 2.0...................................................c...................................................c............124 Oprócz CMP ...................................................c...................................................c...................................129 Rozdział 6. EJB BMP — trwałość zarządzana przez komponenty EJB ...........131 Powtórka z EJB...................................................c...................................................c...............................132 Wzorce BMP ...................................................c...................................................c...................................135 Zarządzanie stanami ...................................................c...................................................c.....................142 Obsługa wyjątków...................................................c...................................................c.........................146 Rozdział 7. Trwałość JDO ..........................................................................................149 JDO czy EJB?...................................................c...................................................c...................................150 Prosta obsługa trwałości za pomocą obiektów JDO ...................................................c...................152 Model trwałości EJB BMP z JDO...................................................c....................................................156 Rozdział 8. Alternatywne wzorce trwałości ...........................................................159 Dlaczego warto stosować alternatywne szablony? ...................................................c.....................160 Sposób realizacji funkcji trwałości ...................................................c.................................................162 Operacje dotyczące trwałości...................................................c..........................................................169 Wyszukiwanie...................................................c...................................................c................................171 Dodatkowe informacje...................................................c...................................................c..................172 Część III Samouczki...................................................c............................173 Rozdział 9. Podstawy J2EE ........................................................................................175 Platforma...................................................c...................................................c.........................................175 Interfejs JNDI...................................................c...................................................c..................................176 JavaServer Pages ...................................................c...................................................c............................187 Zdalne wywoływanie metod ...................................................c...................................................c.......193 Enterprise JavaBeans ...................................................c...................................................c.....................200 Rozdział 10. SQL ...........................................................................................................209 Wprowadzenie ...................................................c...................................................c...............................210 Tworzenie bazy danych...................................................c...................................................c................213 Zarządzanie tabelami...................................................c...................................................c....................215 Zarządzanie danymi ...................................................c...................................................c.....................220 Spis treści 7 Rozdział 11. JDBC .........................................................................................................233 Architektura...................................................c...................................................c....................................233 Prosty dostęp do bazy danych ...................................................c.......................................................238 Zaawansowane zagadnienia JDBC ...................................................c................................................254 Rozdział 12. JDO ...........................................................................................................263 Architektura...................................................c...................................................c....................................264 Ulepszenia...................................................c...................................................c.......................................267 Zapytania ...................................................c...................................................c........................................269 Modyfikacje ...................................................c...................................................c....................................273 Transakcje ...................................................c...................................................c.......................................273 Dziedziczenie ...................................................c...................................................c.................................275 Dodatki...................................................c..................................................277 Skorowidz .......................................................................................................................279 Alternatywne wzorce trwałości Rozum musi we wszystkich swych poczynaniach poddawaeć się krytyce. W przypadku gdy ograniczy wolność krytyki przez zakaz, wyrządzae krzywdę sam sobie, narażając się na niszczące podejrzenia. Nic nie jest tak ważne z poewodu swojej roli ani tak święte, aby mogło być zwolnione z tych analiz, nie znającyche respektu dla żadnej z osób. Rozum zależy od tej wolności przez samo swoje istnienie. Rozum niee ma dyktatorskiego autorytetu, zatem jego werdykt jest zawsze porozumieniem wolnych obywatelie, z których każdy musi mieć prawo do wyrażania, bez nakłaniania lub przeszkadzania, sewoich wątpliwości lub nawet sprzeciwu. — Immanuel Kant Krytyka czystego rozumu Wachlarz możliwości wyboru modelu trwałości dostępny dla projektanta aplikacji o skali przedsiębiorstwa zawiera o wiele więcej możliwości, niż tylko zastosowanie modelu trwało- ści polecanego przez firmę Sun lub opracowanie własnego modelu. Ostatnio popularność zyskują alternatywne modele trwałości. Dzieje się takK z kilku powodów: • komponenty EJB są skomplikowane, mają duży rozmiar i wKymagają zastosowania serwera aplikacji; • zastosowanie interfejsu JDBC jest czasochłonne i wymagaK doświadczenia w programowaniu baz danych; • obiekty JDO to rozwiązanie nowe, które ciągle jeszcze nie jest dostępne we wszystkich implementacjach. Krótkie wyszukiwanie w internecie pozwoli na odnalezienie wielu alternatywnych syste- mów trwałości. Dwa najpopularniejsze projekty to Castor JDO (niebędący implementacją 160 Rozdział 8. Alternatywne wzorce trwałości Wymagania programowe Systemy Castor i Hibernate nie są standardową częścią platformy Javy. Z tego powodu potrzebny jest zestaw tych narzędzi, obsługujący ich interfejsy API. Każdy interfejs API charakteryzuje się innym zbiorem wymagań, o których więcej infor- macji można znaleźć w macierzystych witrynach obu prKojektów, odpowiednio: Castor http://castor.exolabs.com Hibernate http://hibernate.sf.net specyfikacji Sun JDO) oraz Hibernate*. W tym rozdziale opisano projekty Castor i Hiber- nate jako alternatywne narzędzia odwzorowań obiektowo-relacyjnych, wykorzystujące język XML. Dlaczego warto stosować alternatywne szablony? Filozofia Javy jest oparta na zasadzie przestrzegania standardów i rywalizowania w dzie- dzinie implementacji. W świecie Javy należy przyjąć zasadę unikania odchodzenia od standardów, chyba że standardy te nie spełniają wymagań. O modelach trwałości w Javie trudno powiedzieć, że są tworzone według przyjętych standardów. Jednym z powodów rozbieżności poszczególnych modeli jest fakt, iż trudno stworzyć model trwałości, który spełniałby wymagania każdej aplikacji. Każde podejście do trwałości wymaga podejmowa- nia decyzji projektowych, które zmuszają do rezygnacji z właściwości funkcjonalnych udostępnianych przez inne systemy. Każdy alternatywny szablon ma określone zalety, z których warto skorzystać w progra- mowaniu baz danych. Ogólnie, alternatywne szablony charakteryzują się następującymi właściwościami: • Możliwość spełnienia specyficznych wymagań, niespełnionych w standardach EJB i JDO. • Systemy Castor i Hibernate, podobnie jak EJB i JDO do odwKzorowań trwałości wykorzystują pliki deskryptorów XML. Takie rozwiązanie dKoskonale nadaje się do utworzenia zrozumiałego pliku odwzorowania, opisKującego złożone relacje w bazie danych. • Alternatywne systemy zaprezentowane w tym rozdzialeK pozwalają na zminimalizowanie rozmiaru kodu, jaki musi utworzKyć programista po to, aby utrwalić obiekty. * Obydwa są projektami open source dostępnymi w witrynie SourceForge (http://www.sourceforge.net). Dlaczego warto stosować alternatywne szablony? 161 Model „open source” Model open source to sposób rozpowszechniania oprogramowania, oparty na filo- zofii głoszącej, że użytkownicy oprogramowania mają prawo do posiadania kodu źródłowego tego oprogramowania oraz prawo do jego modyfikowania. Chociaż często model ten jest utożsamiany z oprogramowaniem darmowym, to oprogra- mowanie tego typu może, ale nie musi być darmowe. Oprogramowanie open source ma następujące zalety: • Możliwość większej kontroli nad oprogramowaniem włącznKie z możliwością jego usprawniania bez konieczności oczekiwania na pKoprawę błędu przez producenta. • Ze względu na dużą liczbę programistów zaangażowanych w tworzenie takich programów, oprogramowanie open source zwykle charakteryzuje się bardziej zróżnicowanym zapleczem programowym od oprogramowania komercyjnego. • Oprogramowanie open source, nawet jeśli nie jest darmowe, jest zazwyczaj tańsze od komercyjnego. Wynika to stąd, że modele biznKesowe firm zajmujących się produkcją takiego oprogramowania są zoKrientowane przede wszystkim na usługi związane z obsługą systemów. Z drugiej strony, oprogramowanie open source nie jest pozbawione wad: • Serwis techniczny oprogramowania często zależy od woKli jego programistów, a nie jest gwarantowany umową serwisową. • Wydania oprogramowania open source, nad którym nie pracuje zbyt duża grupa programistów, są niespójne a nawet podatne na dłKugie okresy niestabilności. • Korzyści wynikające z większej kontroli nad oprogramKowaniem mogą okazać się fikcyjne, jeżeli utracimy możliwość utrzymania wprowadzonych modyfikacji. • Systemy alternatywne opisane w tym rozdziale to proKdukty open source. W związku z tym charakteryzują się wszystkimi zaletami i wadaKmi narzędzi tego typu. Najlepsze rozwiązanie Alternatywne szablony trwałości należy stosować w applikacjach przeznaczonych dla odbiorców, których podstawowym wymaganiem są niskie koszty oraz aplikacjach o specyficznych wymaganiach, jeżeli takie wymagania spepłniają systemy alternatywne. Alternatywne systemy trwałości mają również swoje wadKy: • Ich interfejsy API zapewniające funkcje trwałości są tyKm, na co wskazuje nazwa — alternatywą. Interfejsy te nie przestrzegają uznanycKh standardów, takich jak EJB 1.1, EJB 2.0, czy JDO. 162 Rozdział 8. Alternatywne wzorce trwałości • Alternatywne systemy trwałości nie zapewniają stosowKania systemu transakcji zarządzanych przez kontenery, podobnego do tego, jakiK oferuje kontener EJB. W przypadku komponentów EJB wyznaczenie ram transakcjKi odbywa się automatycznie po zdefiniowaniu atrybutów transakcji Kw deskryptorze instalacji a kontener wymusza ścisłe przestrzeganie tych ram. Najlepsze rozwiązanie Nie należy stosować alternatywnych szablonów trwałoścpi dla aplikacji, które są przeznaczone do wdrożenia w wielu środowiskach korpopracyjnych. W takich środowiskach przestrzeganie standardów jest kluczowym pczynnikiem, pozwalającym na zdobycie zaufania osób odpowiedzialnych za obsługę aplikacji. Sposób realizacji funkcji trwałości Podobnie jak we wszystkich innych zautomatyzowanych systemach trwałości opisywanych w tej książce, w systemach Castor i Hibernate atrybuty komponentów są utrwalane na podstawie pliku konfiguracyjnego XML, zawierającego definicje odwzorowania trwałości. W tabeli 8.1 wyszczególniono atrybuty dwóch obiektów biznesowych, które mogą zostać utrwalone w bazie danych. Tabela 8.1. Atrybuty dwóch obiektów biznesowych wraSz z typami odwzorowania Klasa Author Book Atrybut AuthorID firstName lastName Publications bookID Author Title Typ Long String String List Long Author String Najlepsze rozwiązanie Chociaż w każdym z szablonów wszystkie odwzorowania tprwałości można umieścić w jednym pliku XML, należy ograniczać objętość każdego ppliku XML, tak aby opisywał odwzorowania pojedynczej klasy. Kod klasy Author opisanej w tabeli 8.1 znajduje się na listingu 8.1. Listing 8.1. Trwała klasa Author package book; import java.util.Set; public class Author { private long authorID; Sposób realizacji funkcji trwałości 163 private String firstName; private String lastName; private Set publications; public long getAuthorID () { return authorID; } public String getFirstName() { return firstName; } public String getLastName() { return lastName; } public Set getPublications () { return publications; } public void setAuthorID (long id) { authorID = id; } public void setFirstName(String fn) { firstName = fn; } public void setLastName(String ln) { lastName = ln; } public void setPublications (Set pubs) { publications = pubs; } } Ta klasa biznesowa jest bardzo prosta — zawiera wyłącznie metody pobierające i ustawiają- ce atrybuty. Nie zawiera kodu utrwalania. Zasadniczy kod dla klasy Book przedstawiono na listingu 8.2. Listing 8.2. Obiekt wartości Book zawierający odwołanie dSo obiektu wartości Author package book; public class Book { private Author author; private long bookID; private String title; public Author getAuthor () { return author; } public long getBookID () { return bookID; } public String getTitle () { 164 Rozdział 8. Alternatywne wzorce trwałości return title; } public void setAuthor (Author auth) { author = auth; } public void setBookID (long id) { bookID =id; } public void setTitle(String ttl) { title = ttl; } } Odwzorowania pól w systemie Castor Kluczowym elementem trwałości w systemach Castor i Hibernate jest plik XML. Każdy interfejs API zawiera własny język, służący do definiowania odwzorowań pomiędzy obiek- tami a tabelą. Na listingu 8.3 pokazano sposób odwzorowania obiektów biznesowych do bazy danych. Listing 8.3. Plik XML deskryptora odwzorowania w systemieS Castor ?xml version= 1.0 ? !DOCTYPE mapping PUBLIC -//EXOLAB/Castor Mapping DTD Version 1.0 å//EN http://castor.exolab.org/mapping.dtd mapping class name= book.Author identity= authorID key-gener;ator= MAX map-to table= AUTHOR / field name= authorID type= long sql name= AUTHORID / /field field name= firstname type= java.lang.String sql name= FIRSTNAHE / /field field name= lastname type= java.lang.String sql name= LASTNAME / /field field name= publications type= book.Book collect;ion= set sql many-key= authorid / /field /class class name= book.Book identity= bookID key-generator;= MAX map-to table= BOOK / field name= bookID type= long sql name= BOOKID / /field field name= title type= java.lang.String sql name= TITLE / /field field name= author type= book.Author sql name= AUTHORID / /field /class /mapping Sposób realizacji funkcji trwałości 165 Dla każdej klasy, która ma zostać odwzorowana w deskryptorze XML, umieszcza się znacznik class*. Znacznik ten ma następujące znaczenie: • określa nazwę odwzorowywanej klasy Javy; • określa nazwę atrybutu tożsamości (atrybut niepowtaKrzalnie identyfikujący egzemplarz klasy); • jest narzędziem generowania kluczy, które można wykoKrzystać do otrzymywania identyfikatorów. W obu systemach, zarówno Castor, jak i Hibernate istnieje kilka sposobów generowania niepowtarzalnych wartości. Najlepsze rozwiązanie Należy wybrać taką metodę generowania sekwencji, którap najlepiej odpowiada wybranemu szablonowi trwałości. System Castor obsługuje następujące algorytmy generowanKia kluczy: HIGH-LOW W tym algorytmie wykorzystano mechanizm podobny do Kopracowanego przez Autora algorytmu generowania sekwencji, który opisanoK w rozdziale 4. Algorytm wymaga specjalnej tablicy sekwencji, której klucze sKą nazwami tabel oraz której kolumny są wartościami zarodków używanych do generowaKnia sekwencji. Więcej informacji na temat wartości zarodków można znaleźć wK części poświęconej generowaniu sekwencji, w rozdziale 4. IDENTITY Generowana wartość wykorzystuje liczbę uzyskaną przezK zastrzeżony mechanizm generowania kluczy dla wybranej bazy danych. Do obsłuKgiwanych baz danych należą Hypersonic SQL, MS SQL Server, MySQL oraz Sybase ASE/ASA. MAX Wygenerowana wartość jest o jeden większa od maksymaKlnej wartości przechowywanej w bazie danych. SEQUENCE Generowana wartość wykorzystuje mechanizm SEQUENCE baz danych Interbase, Oracle, PostgreSQL oraz SAP DB. UUID Ten algorytm generuje globalną unikalną wartość na podstKawie adresu IP, bieżącego czasu systemowego w milisekundach oraz statycznego lKicznika. * Użycie słowa class powoduje, że ten dialekt XML jest technicznie niedozwoplony, gdyż class jest zastrzeżonym słowem języka XML. 166 Rozdział 8. Alternatywne wzorce trwałości Algorytmy SEQUENCE oraz HIGH-LOW wymagają podania parametrów. Parametry te można określić wykorzystując znacznik key-generator, umieszczony poza znacznikiem class: key-generator name = HIGH-LOW param name = table value = Sequence / param name = key-column value = name / param name = value-column value = seed / param name = grab-size value = 1000000 / /key-generator Najlepsze rozwiązanie Należy stosować algorytm generowania kluczy HIGH-LOW. W obszarze otoczonym znacznikami class /class znajduje się zbiór znaczników, które definiują odwzorowania atrybutów klas do bazy danych. Pierwszy znacznik w gru- pie to map-totable. Tak jak sugeruje jego nazwa, określa on nazwę tabeli bazy danych, do której należy odwzorować klasę opisywaną przez znaKcznik. Pozostałe znaczniki zawierają właściwe definicje odwzorowań pól na kolumny. Warto zwrócić szczególną uwagę na znacznik odwzorowujący relację klasy Author z klasą Book. Zamiast definiowania kolumny w tabeli AUTHOR zdefiniowano atrybut w obrębie klasy Book. System Castor wykorzystuje odwzorowanie tej kolumny w celu zrealizowania odpo- wiednich powiązań. Odwzorowania pól w systemie Hibernate Odwzorowania pól w systemie Hiberanate są podobne. Na listingu 8.4 pokazano deskryp- tor XML definiujący odwzorowanie przykładowych klas doK bazy danych. Listing 8.4. Deskryptor XML odwzorowań pól w systemie HibeSrnate ?xml version= 1.0 ? !DOCTYPE hibernate-mapping PUBLIC -//Hibernate/Hibernate Mapping ;DTD å//EN http://hibernate.sourceforge.net/hibernate-mapping-1.;1.dtd hibernate-mapping class name= book.Author table= AUTHOR id name= authorID column= AUTHORID type= long generator class= vm.long / /id property name= firstname column= FIRSTNAME type= st;ring / property name= lastname column= LASTNAME type= stri;ng / set role= publications lazy= true key column= AUTHORID / one-to-many class= book.Book / /set /class class name= book.Book table= BOOK id name= bookID column= BOOKID type= long generator class= vm.long / /id Sposób realizacji funkcji trwałości 167 property name= title column= TITLE / /class /hibernate-mapping Kod odwzorowań w systemie Hibernate jest podobny do kodu odwzorowań w systemie Castor. Istnieje jednak wiele istotnych różnic. Podobnie, jak w systemie Castor, do zdefi- niowania odwzorowań trwałości dla określonych klas Javy, w systemie Hibernate wyko- rzystuje się znacznik class. Inaczej niż w systemie Castor, w systemie Hibernate zdefi- niowano odwzorowania tabel jako atrybut znacznika. Wewnątrz znacznika class należy określić identyfikator, właściwości oraz zbiór klas. Znacznik id opisuje generator wyko- rzystywany do generowania kluczy. W znaczniku tym definiuje się klasę Javy zajmującą się wykonywaniem algorytmu generowania. Jeżeli algorytm wymaga podania parametrów, można je określić w treści znacznika generator, jako znacznik param: generator class= org.dasein.persist.Sequence param sequence /param /generator Klasa generator jest implementacją klasy cirrus.hibernate.id.IdentifierGene årator. W systemie Hibernate dostępne są następujące wbudowane generatory: assigned Umożliwia aplikacji generowanie własnych identyfikatoKrów. hilo.hex Algorytm identyczny z hilo.long, poza tym, że w wyniku jego działania uzyskuje się ciąg 16 znaków. hilo.long Generuje niepowtarzalne wartości typu long wykorzystując algorytm HIGH-LOW. Nie należy stosować tego generatora w środowiskach JTA lKub do połączeń definiowanych przez użytkownika. native Generuje niepowtarzalną wartość na podstawie kolumn iKdentyfikatorów dla baz danych DB2, MS SQL Server, MySQL, Sybase oraz Hypersonic SQL. seqhilo.long Generuje niepowtarzalną wartość typu long dla sekwencji, której przypisano nazwę, z wykorzystaniem algorytmu HIGH-LOW. sequence Generuje niepowtarzalną wartość wykorzystując konstrukKcję SEQUENCE dostępną w bazach danych DB2, Interbase, Oracle, PostgreSQL i SAP DB. uuid.hex Generuje niepowtarzalny ciąg składający się z 32 znaków.K 168 uuid.string Rozdział 8. Alternatywne wzorce trwałości Działanie identyczne z uuid.hex, poza tym, że generowany jest szesnastoznakowy ciąg ASCII. Tego algorytmu nie należy stosować dla bazy daKnych PostgreSQL. vm.hex Generuje niepowtarzalne ciągi znaków na podstawie liczb heksadecymalnych. Tego algorytmu nie należy używać w architekturze klastKra. vm.long Generuje niepowtarzalne wartości typu long. Algorytmu nie należy stosować w architekturze klastra. Najlepsze rozwiązanie W większości platform trwałości dostępnych jest kilkap mechanizmów generowania sekwencji. Ważne, aby wykorzystywać taki mechanizm genperowania sekwencji, który najlepiej odpowiada wysokopoziomowym wymaganiopm architektury (np. podział na klastry). Właściwości są zasadniczymi atrybutami klasy. Z kolei zbiory reprezentują odwzorowania jeden-do-wielu lub wiele-do-wielu dla klasy. W opisywanym przypadku obiekty odwzo- rowują jednego autora na wiele książek. W systemie Hibernate relację tę można określić za pomocą znacznika set. W systemie Hibernate dostępnych jest sześć różnych znKaczników kolekcji: • array • bag • list • map • primitive-array • set Dla tych wszystkich typów zbiorów, poza tablicami, można włączyć późne ładowanie wykorzystując zapis lazy = true . Zastosowanie późnego ładowania umożliwia znacz- ne przyspieszenie szybkości działania aplikacji, szczególnie takich operacji, jak wyszukiwa- nie. Aplikację można także przyspieszyć innymi sposobami, np. poprzez zastosowanie buforowania. Warto zwrócić uwagę, ze większość alternatywnych interfejsów API obsłu- gujących trwałość jest wyposażona w pewnego rodzaju wbudowany mechanizm buforo- wania obiektów, który można włączyć lub wyłączyć. Najlepsze rozwiązanie Wybierając interfejs API do obsługi trwałości ważne jespt właściwe zrozumienie różnych typów odwzorowań obsługiwanych przez wybrany intperfejs. Każdy system trwałości charakteryzuje się innymi niedoskonałościami i może nie zawierać obsługi niektórych złożonych rodzajów odwzorowań jak np.p odwzorowania typu jeden-do-wielu oraz wiele-do-wielu. Operacje dotyczące trwałości 169 Operacje dotyczące trwałości Klasy Author i Book, zaprezentowane na listingach 8.1 i 8.2, nie zawierają metod obsługu- jących funkcje trwałości. Jednak zarówno w systemie Castor, jak i Hibernate wykorzystanie operacji obsługi trwałości wymaga dodania odpowiedniKego kodu. W aplikacjach, które często wykorzystują bazę danych, odświeżanie przesyłanie nowego stanu w bazie danych jest czasochłonnym procesem. Jedną z zalet kontroli nad tym, kiedy następuje to odświeżanie jest możliwość zarządzania Ktymi kosztami. W obu opisywanych systemach trwałości, operacje obsługi trwałości wykonywane są po- przez załadowanie plików odwzorowań, uzyskanie połączenia z bazą danych, wywoła- nie obiektu, który ma zostać utrwalony i zamknięcie transakcji. Wydzielenie kodu obsługi trwałości za pomocą obiektu dostępu do danych pozwala na utworzenie bardziej przej- rzystej implementacji. Najlepsze rozwiązanie Operacje dotyczące trwałości należy umieścić w hermeptycznej klasie, wykorzystując wzorce obiektów dostępu do danych, podobne do tych, którpe wykorzystano w przykładach innych modeli trwałości, zaprezentowanych w tej książce. Dzięki temu z łatwością można przekształcić kod na inny sypstem trwałości, np. EJB. Funkcje obsługi trwałości w systemie Castor W naszym przykładzie potrzebujemy funkcji pozwalającej na dodania nowej książki do listy książek wybranego autora. W systemie Castor metoda służąca do wykonania tego zadania może mieć następującą postać: public Book addBook(Book book) throws Exception { JDO jdo = new JDO( alternativepersistencedb ); jdo.loadConfiguration( database.xml ); Database db = jdo.getDatabase(); db.begin(); db.create(book); db.commit(); db.close(); return book; } Najlepsze rozwiązanie Zastosowanie wzorca projektowego singleton do zarządzania ładowaniem i analizowaniem plików konfiguracyjnych, opisujących operpacje trwałości pozwoli na zwiększenie szybkości operacji obsługi trwałości pw aplikacji. W zaprezentowanym kodzie występuje odwołanie do pliku konfiguracyjnego XML data- base.xml. W pliku tym opisano połączenia z bazą danych, umożliwiające systemowi Castor uzyskanie dostępu do źródła danych JDBC. Na listingu 8.5 pokazano, jak mógłby wyglą- dać taki plik. 170 Rozdział 8. Alternatywne wzorce trwałości Listing 8.5. Deskryptor połączenia z bazą danych w systemiSe Castor !DOCTYPE databases PUBLIC -//EXOLAB/Castor JDO Configuration DTD Version 1.0//EN http://castor.exolab.org/jdo-conf.dtd database name= aps engine= sql-server driver class-name= net.sourceforge.jtds.jdbc.Driver url= jdbc:jtds: åsqlserver://localhost:1433/aps param name= user value= aps / param name= password value= research / /driver mapping href= mapping.xml / /database Dzięki zdefiniowaniu informacji o połączeniu następuje ustanowienie sesji z bazą danych poprzez wywołanie metody klasy JDO getDatabase(). W celu rozpoczęcia transakcji wywołuje się metodę begin() w sesji Database. Po rozpoczęciu transakcji klasa Book jest gotowa do utrwalenia. Wykonuje się to poprzez wywołanie w sesji Database metody create(). Po jej wywołaniu nastąpi utrwalenie nowej książki. Należy teraz wykonać porządkowanie poprzez zamknięcie transakcji za pomocą metod commit() i close() w sesji Database. W przypadku wystąpienia błędu transakcji sesja Database zgłosi wyją- tek TransactionAbortedException. Funkcje obsługi trwałości w systemie Hibernate Obsługa trwałości w systemie Hibernate działa podobnie jak w systemie Castor. Należy wywoływać metody o podobnych nazwach umieszczone w Kinnych klasach: public Book addBook(Book book) throws Exception { Datastore ds = Hibernate.createDatastore(); ds.storeFile( hibernate.xml ); SessionFactory sessionFactory = ds.buildSessionFactor;y(); Session session = sessionFactory.openSession(); session.beginTransaction(); session.saveOrUpdate(book); session.flush(); session.connection().commit(); session.close(); } W pierwszym wierszu kodu wywołano metodę createDatastore(), która załadowała deskryptor połączenia systemu Hibernate (zobacz listing 8.6). Dostępny jest także deskryp- tor połączenia napisany w języku XML. Listing 8.6. Deskryptor połączenia z bazą danych w systemiSe Hibernate hibernate.connection.driver_class=net.sourceforge.jtds;.jdbc.Driver hibernate.connection.url=jdbc:jtds:sqlserver://localhost:143;3/aps hibernate.connection.username=aps hibernate.connection.password=research Po załadowaniu informacji o połączeniu metoda storeFile() wczytuje deskryptor od- wzorowania. Do zarządzania połączeniami sesji w całej aplikacji wykorzystywana jest klasa SessionFactory. W opisywanym przykładzie obiekt klasy SessionFactory Wyszukiwanie 171 tworzony jest dla każdego żądania. W celu rozpoczęcia transakcji wywoływana jest meto- da beginTransaction() dla bieżącej sesji. Następnie wywoływana jest metoda save åOrUpdate() w celu utworzenia lub aktualizacji utrwalanego obiektu. Na końcu cyklu każdej transakcji trzeba wywołać metodę flush(). Operacja wykonywana przez tę metodę ma na celu zsynchronizowanie bazy danych z obiektami w pamięci. Do zatwierdzenia transakcji służy metoda commit(), natomiast zamknięcie transakcji następuje po wywo- łaniu metody close(). W przypadku błędów w czasie transakcji zgłaszany jest wyjątek SQLException. Najlepsze rozwiązanie Obydwa opisane szablony obsługują grupowanie połączeń zp bazą danych lub wykorzystanie źródeł danych JNDI. Warto wykorzystywaćp te możliwości w tworzonych aplikacjach. Wyszukiwanie Wyszukiwanie w obu systemach trwałości przebiega podobnie do wyszukiwania w architek- turze JDO. Systemy te wykorzystują obiektowe języki zapKytań o podobnych interfejsach API. Wyszukiwanie w systemie Castor System Castor wykorzystuje obiektowy język zapytań (ang. Object Query Language — OQL). Zapytania OQL mają zbliżoną postać do standardowych zapytań ANSI SQL, ale zamiast pól określających kolumny występują nazwy obiektów. Implementację wyszukiwania książek w systemie Castor pokazano w na listingu 8.7. Listing 8.7. Wyszukiwanie książek według tytułu w systemiSe Castor public Book findBookByTitle(String title) throws Exceptio;n { JDO jdo = new JDO( alternativepersistencedb ); jdo.loadConfiguration( database.xml ); Database db = jdo.getDatabase(); db.begin(); OQLQuery query = db.getOQLQuery( SELECT b FROM book.Book b WHERE title=$l ); query.bind( Alternative Persistence Systems ); OueryResults results = query.execute(); // zakładamy, że pierwsza znaleziona książka jest tą, którą ;poszukiwano Book book = (Book) results.next(); db.commit(); db.close(); return book; } Podobnie, jak w poprzednio omawianym przykładzie, przed wykonaniem operacji nale- ży załadować informacje konfiguracyjne. Po ustanowieniu połączenia do wyszukiwania są wykorzystywane klasy OQLQuery oraz QueryResults. Najważniejszym wierszem kodu jest wywołanie metody getOQLQuery(). W zaprezentowanej operacji wyszukiwania 172 Rozdział 8. Alternatywne wzorce trwałości interesują nas wszystkie encje, dla których wartość atrybutu title odpowiada argu- mentowi title dostarczonemu do metody wywołującej. W przypadku braku obiektów spełniających kryteria nastąpi zgłoszenie wyjątku NoSuchElementException. Wyszukiwanie w systemie Hibernate Wyszukiwanie w systemie Hibernate przebiega niemal identycznie z wyszukiwaniem w systemie Castor. Implementację wyszukiwania w systemie Hibernate pokazano na listingu 8.8. Listing 8.8. Wyszukiwanie książek według tytułu w systemSie Hibernate public Book findBookByTitle(String title) throws Exceptio;n { Datastore ds = Hibernate.createDatastore(); ds.storeFile( hibernate.xml ); SessionFactory sessionFactory = ds.buildSessionFactor;y(); Session session = sessionFactory.openSession(); Book book = null; List results = session.find( from o in class book.;Book where title = ? , title, Hibernate.STRING); if (results.isEmpty()) { throw new Exception( Nie znaleziono encji: + tit;le); } else { book = results.get(0); } session.close(); return book; } Różnica pomiędzy wyszukiwaniem w systemie Castor a Hibernate polega na tym, że w systemie Hibernate nie jest zgłaszany wyjątek w przypadku braku encji spełniających kryteria. Zamiast tego istnieje metoda isEmpty(), za pomocą której można sprawdzić, czy zapytanie zwróciło wyniki. Dodatkowe informacje Szczegółowy opis każdego z alternatywnych wzorców wykracza poza zakres tej książki. Poza tym systemy Castor i Hibernate nie są jedynymi dostępnymi systemami alternatyw- nymi. Dzięki zapoznaniu się z niniejszym rozdziałem Czytelnik uzyskał ogólny obraz sposobu działania opisanych szablonów. W rozdziale wskazano też elementy, które moż- na przestudiować bardziej szczegółowo a także opisano rolę alternatywnych szablonów trwałości w programowaniu baz danych.
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Java. Aplikacje bazodanowe. Najlepsze rozwiązania
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: