JPA - proste rozwiązania

0

Cześć, szukam prostego rozwiązania do zaimplementowania warstwy danych w aplikacji opartej na JSF i jednym z serwerów (Tomcat, TomEE, GlassFish).

Najchętniej zrobiłbym to oparte o swoje klasy DAO i bezpośrednie odwołania do JDBC (to na razie początki, liczy się prostota), ale wszędzie w przykładach widzę odwołania do JPA i Netbeans bez adnotacji nie generuje encji.

Znalazłem generator FireStorm/DAO, ale jego pełna wersja jest dość droga (prawie $1k).

Pytania:

  • czy znacie jakieś inne generatory klas typu DAO-bez-JPA, najlepiej darmowe lub w rozsądnej cenie
  • czy zastosowanie i konfiguracja JPA w projekcie JSF jest proste (np. OpenJPA lub Glassfish)
  • które rozwiązanie JPA najłatwiej zastosować w ww serwerach aplikacji
  • czy mogę napisać własny driver do JPA? Czy to dużo roboty?
  • czy mieliście jakieś problemy z Hibernate (np. z jego stanem / integralnością), czy wsparcie społeczności tego projektu jest wystarczające
  • jakie jest zastosowanie JPAUtil w przykładzie: http://www.example8.com/category/view/id/241
    (podtrzymanie połączenia do bazy danych? na jak długo?)
0

Na początek: Proste rozwiązanie != JPA/hibernate

Do generowanie Hibernate Tools -> reverse enginiering

1

Jedyne rozwiązanie co czasem alternatywnie stosuje względem JPA to JOOQ:

http://www.jooq.org/

on odzwierciedli Ci całą scheme wybranej bazy w formie klass Javy. Ale nie jest to DAO w sensie usług dostępu do danych.

Jeżeli chciałbyś DAO + JPA to rzuć sobie okiem na Spring JPA Data:

http://projects.spring.io/spring-data-jpa/

masz tam generator DAO (a de facto Repozytoriów według terminologii DDD) na bazie Springowych interfejsów, które możesz rozszerzać, oraz trochę wzorców COC umilających pracę z JPA.

Sam chciałem zastosować do mojego obecnego projektów - lecz z racji że wszystkie usługi muszę mieć przygotowane pod customizacje per wdrożenia via dziedziczenie to robił mi się już za duży clusterfuck z generykami. Ale do normalnych projektów bardzo przyjemnie to wygląda.

A z drugiej strony beczki jak byś szedł w JPA to nie wiem czy DAO jest Ci do szczęścia konieczne. Bo dużo ludzi wpycha ten wzorzec niepotrzebnie do projektów. Jak masz grubego ORM w stylu JPA to w większości projektów szansa że będziesz podmieniał jakieś DAO jest tak duża jak to że pierdalnie Cię piorun ... dwa razy tej samej nocy. Z samego punktu organizacji kodu - niektórzy architekci uważają że "JPA killed the DAO" albo przynajmniej pochłonęło kompetencje DAO w zakresie wymienialności relacyjnej bazy danych:
http://www.adam-bien.com/roller/abien/entry/jpa_ejb3_killed_the_dao
http://www.adam-bien.com/roller/abien/entry/daos_aren_t_dead_but

2

PS.

vpiotr napisał(a):
  • czy zastosowanie i konfiguracja JPA w projekcie JSF jest proste (np. OpenJPA lub Glassfish)

Proste jeżeli zastosuje implementacje JPA co przyszła razem z serwerem.

vpiotr napisał(a):
  • które rozwiązanie JPA najłatwiej zastosować w ww serwerach aplikacji

Te które przyszły razem z serwerem. Nie ma sensu zmieniać jeżeli wymagania projektowe tego nie determinują.

vpiotr napisał(a):
  • czy mogę napisać własny driver do JPA? Czy to dużo roboty?

Lepiej nie próbuj...

vpiotr napisał(a):
  • czy mieliście jakieś problemy z Hibernate (np. z jego stanem / integralnością), czy wsparcie społeczności tego projektu jest wystarczające

Anomalie się zdarzają ale da się wygooglować odpowiedzi na nie. Hibernate ma większą społeczność ale EclipseLink z moich doświadczeń jest trochę lepiej ogarnięty. Z innej strony Hibernate jest bardziej ugruntowany w społeczności wokół Springa, a EclipseLink wokół EJB/CDI.

0

Hibernate to jest dość silnie eksploatowana technologia z której w sumie wyrósł standard JPA, więc raczej nie ma co się obawiać problemów ze stabilnością. Co innego gdybyś chciał korzystać z jakiegoś eksperymentalnego Batoo ;)

0

Nie wiem czy korzystałeś z Hibernate w jakiś większy projekcie ale im bardziej pulchnie Twój model danych tym częściej dostrzegasz jak Hibernate ma niektóre rzeczy z d**y zaimplementowane. Ale oczywiście zawsze znajdziesz jakiś workaround na forum lub zdzirze ;)

Sam wziąłem Hibernate do mojego obecnego projektu z racji że łatwiej ze Springiem współżyje - zwłaszcza z Java Config. Ale jak bym projekt robił na EJB/CDI i Glassfish to EclipseLink nigdy bym nie wymienił na Hibernate. Mają naprawdę silną ekipę i mniej rodzynek wychodzi jak projekt dojrzewa.

0
walec51 napisał(a):

Nie wiem czy korzystałeś z Hibernate w jakiś większy projekcie ale im bardziej pulchnie Twój model danych tym częściej dostrzegasz jak Hibernate ma niektóre rzeczy z d**y zaimplementowane. Ale oczywiście zawsze znajdziesz jakiś workaround na forum lub zdzirze ;)

Sam wziąłem Hibernate do mojego obecnego projektu z racji że łatwiej ze Springiem współżyje - zwłaszcza z Java Config. Ale jak bym projekt robił na EJB/CDI i Glassfish to EclipseLink nigdy bym nie wymienił na Hibernate. Mają naprawdę silną ekipę i mniej rodzynek wychodzi jak projekt dojrzewa.

U nas podobne doświadczenia. Samo hibernate jest stabilny, ale jest w nim sporo błędów które wychodzą z czasem nietrywialne HQL.
Prz naszym aktualnym modelu ponad 1500 encji czas tworzenia sesji (testy) wynosi około 30 sekund. EclipseLink naprawdę jest bardziej dopracowany i częściej zachowuje się logicznie jeśli chodzi o flushe i cache eviction.

Analiza kodu źródłowego hibernate jest kiepska bo kod hibernate jest kiepskiej jakości.

0

im bardziej pulchnie Twój model danych

modelu ponad 1500 encji

Mam wrażenie ze to nie hibernate jest tu problemem tylko zrypany design projektu ;)

Zresztą z punktu widzenia pracy z JPA nie powinno mieć żadnego znaczenia którego dostawcy używasz ;)

0
Shalom napisał(a):

im bardziej pulchnie Twój model danych

modelu ponad 1500 encji

Mam wrażenie ze to nie hibernate jest tu problemem tylko zrypany design projektu ;)

Zresztą z punktu widzenia pracy z JPA nie powinno mieć żadnego znaczenia którego dostawcy używasz ;)

  1. Mam wrażenie ze to nie hibernate jest tu problemem tylko zrypany design projektu ;)
    Tak może być ale istnieją projekty które rzeczywiście mają tyle tabel i 1500 to i tak nie jest tak duża pracując w IT w banku i pisząć system który pokrywał wszystkie aspekty bankowości dla klientów końcowych po punkty obsługi itp mieliśmy 60 schematów każdy średnio po 200 tabel co w sumie daje 12.000 tabel. Oczywiście modułowość OSGI itp. Ale corowy moduł miał ich tak 2500 encji.

  2. Zresztą z punktu widzenia pracy z JPA nie powinno mieć żadnego znaczenia którego dostawcy używasz
    ALe tak nie jest:). Oczywiście nie mówie tutaj o przykładach typu helloworld

0
Shalom napisał(a):

Mam wrażenie ze to nie hibernate jest tu problemem tylko zrypany design projektu ;)

Zresztą z punktu widzenia pracy z JPA nie powinno mieć żadnego znaczenia którego dostawcy używasz ;)

Wybacz ale to praktyka weryfikuje teorie a nie na odwrót...

W praktyce jeżeli robisz coś większego niż proste CRUDy to zaczynasz zauważał białe plamy w specce JPA oraz niedociągnięcia w jej implementacjach. Zwłaszcza jak zaczynasz robić ciekawsze rzeczy z strategią fetch-owania, lock-ami, sortowanymi kolekcjami lub bardziej złożona zapytania w criteria API

1 użytkowników online, w tym zalogowanych: 0, gości: 1