Archiwa tagów: DataNucleus

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 »

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 »