Dopalacze do hibernate

Hej,

Przenosząc się z python na javę myślałem, że orm hibernate jest dużo bardziej rozwinięty niż ten z django. W społeczności pythona sqlalchemy wiedzie prym i myślałem, że hibernate jest czymś ala sqlalchemy z jeszcze lepszymi dopalaczami :D

Najbardziej uderzające porównanie django orm a hibernate dla mnie to sposób budowania zapytań. O ile w django wszystko samo się ładnie składa na podstawie składni pythonowej (QuerySet) to w przypadku hibernate programista robi koślawe NamedQuery :P i własne procedury do wczytania obiektu na podstawie id :]

Co prawda nie siedzę z tym zbyt długo, dlatego ciekaw jestem czy używacie jakiś dodatków do JPA/Hibernate, by wasza praca była efektywna i nie zmuszała do robienia w koło tego samego kodu do obsługi danych.

Pokaż przykłady zobaczymy czy w hibernate da się lepiej

Z tego co kojarze standard JPA na dzien dobry pozwala na:
a) latwe definiowanie named query, ktore miales okazje poznac
b) dynamiczne crieria query, z dosc trudna skladnia
Ta technologia wymaga dosc dlugiego przysiedzenia, aby w niej efektywnie pracowac, ale wygodnie sie tym robi dynamiczne query.

Szukasz czegos bardziej dynamicznego, zainteresuj sie nakladka GORM na Hibernate:
http://grails.org/doc/latest/guide/GORM.html

Wyszedl lekki belkot, napisalem:
<cite>
Ta technologia wymaga dosc dlugiego przysiedzenia, aby w niej efektywnie pracowac, ale wygodnie sie tym robi dynamiczne query.</cite>
Mialem na mysli:
JPA wymaga dosc dlugiego przysiedzenia, aby w tym efektywnie pracowac: ale jest bardzo wygodne jak sie zrozumie o co chodzi.

Pokaż przykłady zobaczymy czy w hibernate da się lepiej

Jako przykład mogę zaproponować większość kodu jaki jest w książkach/stronach wprowadzających w świat hibernate.

1. Robienie od zera managerów zarządzających encją. Niemal pod każdą operację jaką chcesz przeprowadzić na encji trzeba pisać własne metody do tworzenia, usuwania, edycji czy też wszukiwania ;(

2. NamedQuery ma niezbyt pozytywną ideę. Pisanie sql w orm powinno być bardziej wyjątkiem niż zasadą.

Ja tam piszac w JPA/EclipseLink przyzwyczailem sie do JPQL i uwazam za sensownie rozwiazanie. Na pewno zauwazyles, ze to nie jest SQL bo operuje na encjach, a nie kolumnach. Poza tym IDE (np. NetBeans) elegancko wspiera pisanie zapytan, wiec robi sie to bardzo efektywne.

1. Robienie od zera managerów zarządzających encją. Niemal pod każdą operację jaką chcesz przeprowadzić na encji trzeba pisać własne metody do tworzenia, usuwania, edycji czy też wszukiwania ;(

Nie chcę tu zbytnio bronić Hibernate'a (używam, nie lubię) ale kto Tobie każe pisać te managery?
Przecież wystarczy choćby Spring Data sobie ściągnąć. Oj, rozleniwiło kogoś posiadanie wszystkiego w jednym pakiecie.

W ogóle tego nie porównuj. Python i Java to dwa zupełnie inne języki z zupełnie inną składnią i możliwościami. Zatem i ORMy będą dysponować zupełnie innymi możliwościami i konstrukcjami.

ad 1. Nie prawda. Wystarczy użyć dziedziczenia i napisać jedno generyczne DAO. W klasach dziedziczących tworzymy metody doprecyzowujące zapytania.
ad 2. Masz Criteria API, które pozwala w przeciwieństwie do NamedQuery na pisanie kodu w oparciu o obiektową naturę języka. W dodatku masz sprawdzanie typów w czasie kompilacji. Jak ci powiem, że jeszcze są NativeQuery to zapewne już za bardzo namieszam.