Archiwa kategorii: JPA

Criteria API multiselect i różnice w implementacjach JPA

Tworzenie zapytań w JPA to rzecz zarazem łatwa jak i trudna. Łatwa, bo bardzo prosto jest stworzyć zapytanie oparte o zwykłego SQL’a lub JPQL’a, a nawet zapytania tworzone za pomocą Criteria API nie są czymś nadzwyczajnym. Zarazem jest to jednak trudny temat, bo trzeba pamiętać o wielu kwestiach związanych z wydajnością lub bezpieczeństwem, których pominięcie może spowodować spore problemy w przyszłości. Nie chcę tu się rozpisywać po trochu o wszystkim, a poruszyć jeden temat, który zaciekawił mnie szczególnie.

Jedną z ważniejszych rzeczy związanych z projektowaniem zapytań do bazy danych jest zawężanie zapytań w taki sposób, aby zwracały tylko niezbędne do konkretnego widoku aplikacji dane. Gdy używamy technologii ajaxowych (np. GWT), ogranicza to nam ilość przesyłanych danych do przeglądarki, a nawet jeśli nie, to mniej cierpi na tym serwerowy cache (jeśli go włączyliśmy). JPA dostarcza kilka rozwiązań, które umożliwiają zawężenie wyników zapytań, a ciekawsze z nich to Constructor Expression wykorzystane wraz z Named Queries, oraz multiselect w Criteria API. Ciekawsze, bo oba pozwalają zmapować zapytanie bezpośrednio na konstruktor klasy DTO. Dziś będzie o tylko o tym drugim, czyli o metodzie multiselect.

Czytaj więcej »

Relacja wiele-do-wielu i Criteria API w JPA 2.0

Jakiś czas temu zapowiadałem pojawienie się artykułu na temat relacji wiele-do-wielu zrealizowanej za pomocą RequestFactory w GWT. Od tamtej pory trochę wody w Wiśle upłynęło, a ja z braku czasu nie miałem kiedy napisać o swoich poczynaniach. Jako że miniony weekend znalazłem trochę czasu i spędziłem go pod znakiem GWT, postanowiłem nadrobić zaległości.

Zdecydowałem się jednak rozdzielić temat RequestFactory od tematu JPA i opisać te dwa zagadnienia osobno. Podyktowane jest to przede wszystkim chęcią rozpisania się trochę o tym pierwszym, a i w związku z JPA chciałbym przedstawić kilka ciekawostek. Materiału trochę jest, więc zebranie tego wszystkiego razem tylko wydłużyłoby czas oczekiwania na nowy wpis. Sam projekt, a raczej kontynuacja tego rozpoczętego przy pierwszych bojach z RequestFactory i rozwijanego dalej podczas opisu możliwości walidacji encji w JPA i GWT, jest już prawie na ukończeniu i można go pobrać z repozytorium.

Relacja wiele-do-wielu (many-to-many) jest chyba najtrudniejszą relacją do zamodelowania i zrozumienia dla początkujących programistów. Jako jedyna po stronie bazy danych wymaga utworzenia osobnej tabeli (tzw. intersekcji) łączącej rekordy dwóch głównych tabel. Z tego też powodu zazwyczaj sprawia najwięcej trudności przy mapowaniu tabel na encje za pomocą JPA (podobnie zresztą w czystym Hibernate). Upraszczając problem, relację wiele-do-wielu można rozłożyć na dwie relacje jeden-do-wielu (one-to-many) i dołożyć mapowanie osobnej encji pełniącej rolę intersekcji. Wtedy jednak w encjach głównych dostaniemy bezpośredni dostęp za pomocą kolekcji jedynie do encji intersekcji, a nie do siebie nawzajem. Jak więc poprawnie napisać mapowanie wiele-do-wielu używając adnotacji @ManyToMany?
Czytaj więcej »

JPA i walidacja encji w projekcie GWT

Całkiem niedawno opisywałem moje boje z mechanizmem RequestFactory, który okazał się być całkiem fajnym tworem. Za jego pomocą udało się nam wtedy stworzyć aplikację z serwisami zorientowanymi na dane, gdzie warstwę dostępu do danych zapewniał nam Hibernate. Aplikacja potrafiła wykonać jedynie podstawowe operacje CRUD na pojedynczej encji i już wtedy zapowiedziałem, że w dalszym ciągu czekają na nas relacje między encjami oraz walidacja encji. Dzisiaj będę kontynuować stworzony wtedy projekt i zajmę się drugim z zapowiedzianych tematów, czyli normą JSR 303 definiującą reguły sprawdzania poprawności obiektów. Walidacja nie będzie skomplikowana i ma na celu jedynie pokazanie działania wraz z mechanizmem RequestFactory.

Aby materiału na dzisiaj nie było za mało, pokażę jak skonfigurować projekt, aby skorzystać ze standardu JPA, którego API zastąpi nam Hibernate’a. Ten ostatni będzie dalej obecny pod postacią dostawcy implementacji JPA, jednak jak zauważymy później, kod źródłowy będzie całkowicie od niego niezależny. Przy okazji pokuszę się o małe porównanie JPA z Hibernate’m.

Zacząłem trochę inaczej niż zawsze, gdyż na wstępie zazwyczaj skupiam się na sensowności/celu zastosowania danej technologii, a nie na tym co będziemy robić. Jeśli czujesz się trochę zawiedziony, to już to nadrabiam :) Po co używać więc JPA, jeśli mamy w projekcie doskonale działającego Hibernate’a? Po co uczyć się nowego, nieco innego API? Czy użycie JPA ma jakieś zalety, ewentualnie wady? Odpowiedzi na te pytania mogą być różne i wszystko zależy od tego, jaką aplikację tworzymy i w jakim środowisku będzie ona pracować. Przede wszystkim należy pamiętać, że Hibernate nie jest jedynym narzędziem ORM’owym i istnieje cała masa alternatywnych rozwiązań. Możemy np. trafić do zespołu, który będzie faworyzował Oraclowego TopLink‚a, bądź rozwijanego przez fundację Apache – Open JPA. Możemy też być uzależnieni od środowiska, np. osadzenie aplikacji na serwerze Google App Engine będzie wymagało od nas użycia DataNucleus‚a.

Czytaj więcej »