|
[ Pobierz całość w formacie PDF ]
nych narzucane przez niektóre systemy szkieletowe, na przykład struts-config.xml z Struts, są głównym czynnikiem powodującym powstanie hasła piekło meta- danych . Wiele plików odwzorowań wczytuje się, wielokrotnie wywołując metodę addResource(). Ewentualnie, gdy programista stosuje się do przedstawionej powy- żej konwencji, może użyć metody addClass(), przekazując jako parametr klasę trwałą. SessionFactory sessions = new Configuration() .addClass(org.hibernate.auction.model.Item.class) .addClass(org.hibernate.auction.model.Category.class) .addClass(org.hibernate.auction.model.Bid.class) .setProperties(System.getProperties()) .buildSessionFactory(); Metoda addClass() zakłada, że nazwa pliku odwzorowania kończy się rozszerze- niem .hbm.xml i znajduje się w tym samym folderze co odwzorowywany plik klasy. Przedstawimy tworzenie pojedynczego obiektu SessionFactory, ponieważ takie podejście występuje w aplikacjach najczęściej. Jeśli potrzebny jest kolejny obiekt, bo na przykład istnieje kilka baz danych, cały proces powtarza się od nowa. W ten sposób zawsze istnieje jeden obiekt SessionFactory na bazę danych gotowy do tworzenia obiektów Session działających z tą bazą danych i zestawem odwzo- rowań klas. Konfiguracja Hibernate to nie tylko wskazanie dokumentów odwzorowań. Trzeba również wskazać sposób uzyskania połączenia z bazą danych oraz określić zachowanie Hibernate w różnych sytuacjach. Mnogość dostępnych właściwości konfiguracyjnych potrafi przytłoczyć (pełna ich lista znajduje się w dokumentacji 62 ROZDZIAA 2. Wprowadzenie i integracja Hibernate Hibernate). Na szczęście większość parametrów stosuje sensowne wartości do- myślne, więc najczęściej potrzeba zmienić tylko ich niewielką część. Aby określić opcje konfiguracyjne, korzysta się z jednej z wymienionych technik. Przekazuje się egzemplarz klasy java.util.Properties jako parametr metody Configuration.setProperties(). Ustawia się właściwości systemowe za pomocą konstrukcji java -Dwłaściwość=wartość. Umieszcza się w ścieżce wyszukiwania klas plik o nazwie hibernate. properties. Dołącza się elementy do pliku hibernate.cfg.xml znajdującego się w ścieżce wyszukiwania klas. Techniki pierwszą i drugą stosuje się naprawdę rzadko jedynie w trakcie testów lub szybkiego prototypowania. Większość aplikacji potrzebuje stałego pliku konfi- guracyjnego. Oba pliki, hibernate.properties i hibernate.cfg.xml, pełną tę samą funkcję konfigurują Hibernate. Wybór pliku zależy tak naprawdę od własnych preferencji co do składni właściwości. Możliwe jest nawet mieszanie obu technik i posiadanie osobnych ustawień dla środowiska testowego i wdrożeniowego. Przed- stawimy to zagadnienie w dalszej części rozdziału. Bardzo rzadko stosowanym rozwiązaniem alternatywnym jest przekazywanie przez aplikację obiektu Connection z JDBC w momencie tworzenia obiektu Session dzięki obiektowi SessionFactory (powstaje wtedy kod typu sessions.openSession (myConnection)). Opcja ta pozwala nie podawać w trakcie konfiguracji żadnych opcji związanych z połączeniem z bazą danych. Nie polecamy takiego podejścia dla nowych aplikacji, które mogą skorzystać z infrastruktury połączeń bazodano- wych całego środowiska (na przykład wykorzystując pulę połączeń JDBC lub zró- dła danych serwera aplikacji). Ze wszystkich opcji konfiguracyjnych najważniejsze są ustawienia połącze- nia bazodanowego. Różnią się w zależności od tego, czy stosuje się środowisko zarządzane czy niezarządzane. Z tego względu opis rozbijemy na dwa przypadki. Zacznijmy od środowiska niezarządzanego. 2.3.2. Konfiguracja w środowisku niezarządzanym W środowisku niezarządzanym, na przykład kontenerze serwletów, aplikacja odpowiada za uzyskanie połączeń JDBC. Hibernate jest częścią aplikacji, więc również może uczestniczyć w ich uzyskaniu. Plik konfiguracyjny informuje, w jaki sposób Hibernate może uzyskać (lub utworzyć nowe) połączenia JDBC. Ogól- nie nie zaleca się tworzenia połączeń za każdym razem, gdy tylko chce się skorzy- stać z bazy danych. Aplikacja Javy powinna zatem używać puli połączeń JDBC. Istnieją trzy powody przemawiające ze stosowaniem puli: Uzyskiwanie nowych połączeń jest kosztowne. Utrzymywanie wielu niewykorzystywanych połączeń jest kosztowne. 2.3. Konfiguracja podstawowa 63 Tworzenie instrukcji przygotowanych dla niektórych sterowników również jest kosztowne. Rysunek 2.2 przedstawia rolę puli połączeń JDBC w środowisku wykonawczym aplikacji internetowej. Ponieważ samo środowisko nie udostępnia puli połączeń bazodanowych, aplikacja musi wprowadzić własny algorytm tworzenia puli lub stosować w tym celu niezależną bibliotekę, na przykład udostępnianą na zasadach [ Pobierz całość w formacie PDF ] |
Odnośniki
|