Archiwum

Archive for Styczeń 2011

Opakowanie wynik zapytani JPA do DTO

25/01/2011 Dodaj komentarz

Ten wpis jest rodzajem koncepcji (życzenia) pewnego usprawnienia jakie by mi się przydało przy pracy z JPA. Może to być także usystematyzowaniem tego co chcę i odkryciem, że problem i ewentualne rozwiązanie leży gdzie indziej.

Pisząc ostatnio zapytania w JPA (stary sposób) typu:

List persons = entityManager.createQuery("SELECT p FROM Person p").getResultList();

Miałem potrzebę, głównie ze względów wydajnościowych, ograniczenia zwracanych szczegółów w obiektach. Można to zrobić poprzez użycie DTO i wydania odpowiedniego zapytania do napełnienia pożądanych wartości w nim. Ja ze względu na zastany kod (wprowadzenie nowej klasy propagowałoby zmian wyżej) i wygody chciałem użyć wcześniejszą klas encji w tej roli. Co wygląda jak poniżej:

List persons = entityManager.createQuery("SELECT new Person(p.id, p.name) FROM Person p").getResultList();

No i jest, i dział, ale w moim (rzeczywistym) przypadku wiązało się to z przekazaniem większej liczby wartości i także stworzeniem odpowiedniego konstruktora. Czyli dużo klepania kodu w zapytaniu oraz w kodzie konstruktora. Są dwa odległe miejsca zależne od siebie, przez to można łatwo wprowadzić błąd. W przypadku gdy konstruktor przyjmuje 10 stringów, pomyłka w przypisaniu tych wartości może być łatwa do wprowadzona (choćby przestawienie dwóch wartość o tym samym typie).

Problem
Tak więc cała koncepcja ulepszenia tego sprowadza się do odpowiedzenia na pytanie: Czy nie można tego jakoś wyrazić w jednolity sposób? Tak aby mieć pewność, że konstruktor dobrze przypisuję wartości, i zapytanie jest dobrze złożone.
Dotychczas trzymałem oba kawałki kodu obok siebie, tak aby łatwiej widzieć ewentualne błędy. Później wprowadziłem automat do budowania stringa konstruktora, który eliminował pewne pomyłki (można było na przykład wprowadzić sprawdzenie czy konstruktor wyrażony w stringu da się odnaleźć). Rozwiązania te nie są idealne i są kłopotliwe w implementacji.

Uaktualnienie: poniżej są dywagacje jak to chciałbym zrobić – znalazłem rozwiązanie tego problemu w trochę inny sposób. Materiały mówiące o tym tu lub tu. A to jak później zrobiłem na podstawie tego tutaj.
Czytaj dalej…

Reklamy
Kategorie:Java Tagi: ,

Tail recursive

25/01/2011 Dodaj komentarz

Zaczyna się jak kolejny wpis w stylu „java też tak może” (przykład innego tutaj).
Ostatnio doszła mnie wieść o cesze języka Scala, która to kryje się za pojęciem ‚tail recursive’. Poszukiwanie tego co to znaczy doprowadziło mnie między innymi do tego wpisu. Jest tu w miarę łopatologiczne wytłumaczenie o co chodzi w tym. Upraszczając: za tym pojęciem kryje się rodzaj pisania rekurencji w ten sposób, aby nie doprowadzić do jej wyłożenia się kiedy będzie biegła ona ku (prawie) nieskończoności.
Rekurencja nie jest mym chlebem powszednim w javie (i nie tylko) ;). Ciekawe czy jest to rodzaj wpojonego przekonania, czy z biegiem lat nabyte podskórne przekonanie, że nie tędy droga? Generalnie wiem, że w javie jest to możliwe, ale stosowanie tego w nadmiarze (nie rozważnie) może prowadzić do braku pamięci.
Wpis, do którego się tu odnoszę, podpuścił mnie do sprawdzenia czy może jedna java da radę.
Czytaj dalej…

Kategorie:Java Tagi: ,