13 listopada 2006

Hibernate jako dostawca JPA w samodzielnej aplikacji

Tym razem nadszedł czas na Hibernate w roli dostawcy JPA i po niecałej godzinie miałem gotową aplikację zmigrowaną do Hibernate EntityManager'a (aka Hibernate JPA). Prostota JPA jest niebywała i choć należy oczekiwać pewnych niedogodności na razie omijają mnie szerokim łukiem ;-)

Podsumujmy dotychczasowe wyniki pracy z JPA. Stworzyłem aplikację z pomocą NetBeans IDE 5.5, który umożliwił mi skorzystanie z implementacji JPA w wydaniu Oracle TopLink. Nie modyfikując nic w aplikacji (poza konfiguracją JPA) uruchomiłem ją z Apache OpenJPA. A dzisiaj nadeszła pora na Hibernate. Mimo tych niezwykle krótkotrwałych wypadów w świat JPA, już daje zauważyć się pewne różnice. Daje zauważyć się doświadczenie projektu Hibernate i jego prostota użycia. Ale, skoro są to jedynie szczegóły implementacyjne, kto by się tym zajmował. Implementacje JPA (Oracle TopLink, Apache OpenJPA, Hibernate) staną się (stały się?) podobnym rozwiązaniem jak sterowniki JDBC.

Dzisiejsze doświadczenia zaowocowały kolejnym przepisem - Hibernate jako dostawca JPA w samodzielnej aplikacji.

Najwyższa pora zająć się czymś z Java EE 5 na dłużej. Czas na zabawę z implementacjami JSF 1.2 i ich integracja z JPA. Może JBoss Seam? Nie! Na razie wystarczy Glassfish i samo zapoznanie się z nowościami JSF 1.2, a mówi się, że jest ich wiele.

5 komentarzy:

  1. Jacek,

    a co z adnotacjami JPA gdy używamy Hibernate? Hibernate dostarcza ich w pakiecie org.hibernate.annotations, i to nie wszystkich, np. nie ma adnotacji @Id. Czy trzeba/można dorzucić także pakiet javax.persistence jako osobny .jar? Dystrybucja TopLink go zawiera od razu.

    OdpowiedzUsuń
  2. Jedyny słuszny pakiet dla adnotacji JPA to javax.persistence. Wszystkie inne są rozszerzeniami, typami specyficznymi dla dostawcy JPA, nieprzenośnymi itp. Nie używaj ich, bo związujesz się z produktem, a nie specyfikacją. Faza korzystania z adnotacji nie powinna już wiązać z produktem - zdecydowanie za wcześnie. Zgadzam się, że należy rozważyć rozszerzenia specyfikacji przy konkretnych zastosowaniach, ale jeśli nie trzeba, nie robimy tego.

    Najlepiej od razu zapomnieć o Hibernate jako dostawcy JPA i użyć OpenJPA, który jest w 100% zgodny z JPA TCK, co w przypadku Hibernate jest jeszcze w powijakach. Hibernate fajny, ale OpenJPA również, a może i lepszy? ;-)

    OdpowiedzUsuń
  3. Czyli to co jest na stronie Hibernate:

    "The Hibernate Java Persistence provider is fully certified and passes the Sun TCK."

    to nie do końca prawda? Pamiętam, że pisałeś w innych artykułach o jakichś "małych" niedociągnięciach w Hibernate, ale czy żeczywiście jest aż tak źle że Hibernate "jest jeszcze w powijakach"? Rozumiem, że kolejną alternatywą, oprucz OpenJPA, jest TopLink. Przyznam, że obawiam się troche o stabilność i poręczność OpenJPA ale jest to tylko i wyłącznie na zasadzie strachu przed nieznanym. Zapewne kiedyś poznam :)

    OdpowiedzUsuń
  4. Widziałem to stwierdzenie, ale co tak na prawdę oznacza Sun TCK? Czy chodzi o JPA TCK? Czy może inne ze stajni Suna? Natrafiłem na tyle podstawowych błędów w Hibernate JPA (np. natywne zapytania, odliczanie parametrów nazwanych od 0), że wątpię, aby było to JPA TCK, chociaż nie wszystkie elementy specyfikacji mogą być testowane, albo obligatoryjne. Z mojego (i tylko mojego) doświadczenia nie nazwałbym Hibernate zgodnym z JPA TCK i raczej będę starał się unikać korzystania z niego jako dostawcy JPA.

    Nie mogę nigdzie znaleść wiadomości, w której Gavin King, czy ktoś z zespołu Hibernate ogłaszałby tę zgodność publicznie, więc poza tą notką nie ma nic namacalnego plus...kilka poważnych błędów.

    Odnośnie OpenJPA to nie ma się czego obawiać. Projekt ma silne podstawy produktowe - produkt Kodo i teraz ze spełnieniem wymogów JPA TCK i oficjalnym tego ogłoszeniem spodziewam się, że ilość wiadomości na liście OpenJPA będzie równie wysoka jak Hibernate, jeśli nie przewyższy jej. Wzrośnie jego popularność, więc i zmieni się Twoje nastawienie.

    Wszystko to kwestia albo doświadczenia, albo przyzwyczajeń. Skoro przyzwyczajenia budowane są na bazie doświadczeń, a JPA jest wystarczająco młode, aby wyrobić sobie dobre przyzwyczajenia, więc proponuję od razu popróbować się z OpenJPA i...opisać doświadczenia na swoim blogu. Kilka innych osób zapozna się z Twoim zdaniem i społeczność OpenJPA wzrośnie, to spowoduje dalszy rozwój projektu, a że ma (również) dobre wsparcie komercyjne, więc można przypuszczać, że będzie to numer 1 wśród dostawców JPA w niedługim czasie.

    OdpowiedzUsuń
  5. Dzięki za odpowiedź. Nie dość że odpowiadasz na pytanie które zadałem, to jeszcze na to które chciałem zadać. Właśnie zacząłem się bliżej przyglądać OpenJPA, tj. otworzyłem dokumentacje, patrze a tu KODO! No i jak widze nie myliłem się.

    Jak trafiłem na OpenJPA? Rozgryzam teraz następujące zagadnienie - Jak sprawić żeby Lista to rzeczywiście była lista, tj. aby kolejność też była utrwalana. Z tego co widzę to OpenJPA oferuje coś takiego. Niestety, nie widzę póki co sposobu aby potem móc pisać zapytania gdzie używam tej kolejności, np. w sekcji ORDER BY, albo jeszcze lepiej, jako argument funkcji MIN(). Swoją drogą, uważam to za błąd specyfikacji że wymaga ona aby własności o typie List były obsługiwane, ale nie wymaga przy tym aby implementacja zachowywała kolejność. Przecież to jest lista a nie multizbiór.

    OdpowiedzUsuń