Czy warto JPA?

0

Cześć - paru znajomych polecało mi JPA, inny radzili jednak zostanie przy Hibernate. A Wy co o tym sądzicie? Bardzo zależy mi na wydajności, pracuję przy bazach danych Oracle i dla mnie kluczowa jest możliwość pisania optymalnych zapytań.

1

A wiesz że JPA to tylko specyfikacja ? pod spodem i tak zazwyczaj siedzi hibernate...

0
niezdecydowany napisał(a):

A wiesz że JPA to tylko specyfikacja ? pod spodem i tak zazwyczaj siedzi hibernate...

To może jakieś inne rozwiązanie polecisz? Chodzi mi o łatwe mapowanie wyników zapytań i jednocześnie kontrolę nad składnią zapytań.

0

spring jdbc template ? ale co to jest kontrola składnia zapytań ? jeżeli nie znasz takich podstaw jak różnicę między jpa a hibernate to domyślam się że i Twój kod jest prosty i problem z performencem nie występuje, możesz korzystać z ficzerów do generowania zapytać z jpa/hibernate, zero problemu.

0
niezdecydowany napisał(a):

spring jdbc template ? ale co to jest kontrola składnia zapytań ? jeżeli nie znasz takich podstaw jak różnicę między jpa a hibernate to domyślam się że i Twój kod jest prosty i problem z performencem nie występuje, możesz korzystać z ficzerów do generowania zapytać z jpa/hibernate, zero problemu.

Chodzi mi np. o możliwość stosowania hintów w Oracle.

0

Nie korzystam z hintów, bo jestem postgresowcem i tam ich nie ma. Ale ludzie robią takie rzeczy, sprawdź czy tego szukasz:
http://www.mkyong.com/hibernate/how-to-embed-oracle-hints-in-hibernate-query/

Ogólnie dodam od siebie, że Hibernate potrafi więcej jak JPA. Jest też pełną implemetacją stanardu. Na innych serwerach aplikacyjnych możesz znaleźć różne domyślne implementacje np. OpenJPA na TomEE lub EclipseLink na GlassFishu (referencyjna JPA).

Było o tym pisane wiele razy, ale standard JPA pochodzi od Hibernate: ustandaryzowano to co już jest.

0

Dzięki, przyjrzę się :)

0

Warto wybrać JPA jeśli nie wiesz na jakim serwerze aplikacyjnym będzie pracowała Twoja aplikacja. Na przykład piszesz jakiś CMS który będziesz sprzedawał różnym klientom, i część z nich ma już Weblogic, część Websphere, część JBoss...
Jeśli jednak wiesz, że pod spodem będzie baza Oracle to zakładam, że znasz też serwer aplikacyjny (a może to Weblogic, czyli implementacja TopLink). Wtedy można pisać pod konkretną implementację, i korzystać ze specyficznych dla niej ficzerów.

0
ce59fef8 napisał(a):

konkretną implementację, i korzystać ze specyficznych dla niej ficzerów.

Czyli chcesz stracić główną zaletę JPA ...
user image

0

@niezdecydowany nie do końca. Dużo zależy od tego na jakim poziomie połączymy taki specyficzny kod z naszą apką. Jeżeli przez jakieś pośrednie API to wymiana bazy danych będzie w miarę prosta i ograniczy się tylko do przepisania implementacji takiego pośrednika.

0
Koziołek napisał(a):

@niezdecydowany nie do końca. Dużo zależy od tego na jakim poziomie połączymy taki specyficzny kod z naszą apką. Jeżeli przez jakieś pośrednie API to wymiana bazy danych będzie w miarę prosta i ograniczy się tylko do przepisania implementacji takiego pośrednika.

jasne,spoko, wydzielenie do tego jakiegoś mikroserwisu, ale robienie tego w "DAO" będzie hardcorem

1
niezdecydowany napisał(a):
ce59fef8 napisał(a):

konkretną implementację, i korzystać ze specyficznych dla niej ficzerów.

Czyli chcesz stracić główną zaletę JPA ...

No tak, ale świadomie :), kiedy ta uniwersalność przestaje być zaletą, a zaczyna być wręcz wadą, bo ogranicza. Jeżeli piszemy aplikację sami dla siebie, to można sobie zaszaleć i użyć np. @Filter.

0
ce59fef8 napisał(a):
niezdecydowany napisał(a):
ce59fef8 napisał(a):

konkretną implementację, i korzystać ze specyficznych dla niej ficzerów.

Czyli chcesz stracić główną zaletę JPA ...

No tak, ale świadomie :), kiedy ta uniwersalność przestaje być zaletą, a zaczyna być wręcz wadą,.

To po uj wtedy JPA używasz ?

0

@niezdecydowany, bo zazwyczaj takie nietypowe elementy to jakieś 10% całości.

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