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

0

O - właśnie dzisiaj natafiłem na mój ulubiony stacktrace Hibernate'a:

Caused by: javax.persistence.PersistenceException: [PersistenceUnit: default] Unable to build EntityManagerFactory
	at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:924)
	at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:899)
	at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:76)
	at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:287)
	at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:310)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1607)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1544)
	... 57 more
Caused by: org.hibernate.loader.MultipleBagFetchException: cannot simultaneously fetch multiple bags
	at org.hibernate.loader.BasicLoader.postInstantiate(BasicLoader.java:93)
	at org.hibernate.loader.entity.EntityLoader.<init>(EntityLoader.java:118)
	at org.hibernate.loader.entity.EntityLoader.<init>(EntityLoader.java:70)
	at org.hibernate.loader.entity.EntityLoader.<init>(EntityLoader.java:53)
	at org.hibernate.loader.entity.BatchingEntityLoaderBuilder.buildLoader(BatchingEntityLoaderBuilder.java:75)
	at org.hibernate.persister.entity.AbstractEntityPersister.createEntityLoader(AbstractEntityPersister.java:2483)
	at org.hibernate.persister.entity.AbstractEntityPersister.createEntityLoader(AbstractEntityPersister.java:2496)
	at org.hibernate.persister.entity.AbstractEntityPersister.createLoaders(AbstractEntityPersister.java:3842)
	at org.hibernate.persister.entity.AbstractEntityPersister.postInstantiate(AbstractEntityPersister.java:3828)
	at org.hibernate.persister.entity.SingleTableEntityPersister.postInstantiate(SingleTableEntityPersister.java:1018)
	at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:461)
	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1769)
	at org.hibernate.ejb.EntityManagerFactoryImpl.<init>(EntityManagerFactoryImpl.java:96)
	at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:914)

Wszystko zgodnie z specką JPA, a jednak - znany i lubiany błąd. W jakieś klasie wymagam conajmniej dwóch EAGER fetchingów, z którym akurat Hibernate sobie nie poradzi. EclipseLink jeszcze nie udało mi się takimi podstawami zaskoczyć. Zapowiada się radosne 1 h szukania, o którą encje chodzi bo Hibernate Ci tego oczywiście nie powie...

0

@walec51 oj tam oj tam, zamień List<T> które masz w klasie na Set<T> i problem zniknie :P

0

Ta wiem, pytanie gdzie :P i czy mogę - bo w niektóre relacje onetomany mam sortowane.

PS. Jeszcze inną rodzynkę dzisiaj znalazłem - tym razem to akurat biała plama w JPA:
https://hibernate.atlassian.net/browse/HHH-7635
co myślicie o tym diagramie co podrzuciłem ? przykład z d*py czy realny case ?

0

I kolejny bug w Hibernate znaleziony:

https://hibernate.atlassian.net/browse/HHH-8766

tym razem w dwulinijkowym JPQL'u

Konkluzja: jak masz wybór - to idź w EclipseLink

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