EntityManager zamiast szablonu JDBC znanego ze Spring

Witam,
Tworzę aplikację na serwerze WebLogic (12.1.3c) komunikującą się z bazą danych wykorzystującą rozwiązania GIS dla Oracle, mapy itp. Aplikacja musi być osadzona na jedynym słusznym serwerze aplikacyjnym i być zintegrowana z narzędziami Oracle. Na tym serwerze działać będzie jeszcze wiele innych aplikacji.

Do komunikacji z bazą używam natywnego SQL-a. Nie chcę używać cache, ani encji (poza tym tabele GIS nie mają PK). Idealnym rozwiązaniem byłby szablon Spring JDBC z jaki z powodzeniem używałem na Tomcat. Jednak to są dodatkowe biblioteki, których fajnie uniknąć.

Zintegrowałem to tak, że robię natywne zapytania przez EntityManager, podpięty do JNDI DataSource (nie posiadając ani jednej encji, mając wyłączony cache). Wszystko odbywa się za pomocą zapytań natywnych. Działa.

Alternatywnie mógłbym wstrzykiwać JDBC data source, bez definiowania @PersitanceUnit. Zdecydowałem się jednak, że to słaby pomysł bo JPA eliminuje mi boilerplate JDBC (wyjątki i zamykanie zasobów).

Pytanie:
Czy Waszym zdaniem zastosowanie JPA do natywnych zapytań, bez cache i encji, to lepszy pomysł niż czyste JDBC za pomocą @Resurce(lookup = "/jndi/bazads")?

Moim zdaniem tak, bo jest mniej boilerplate (a Spring byłby tutaj redundantny, bo i tak mam API JPA dostępne na serwerze, więc ciężko mówić o armacie na muchę, co byłoby prawdą gdybym uruchamiał apkę np. na Tomcat).

Pozdrawiam,

To już chyba lepiej JDBC, przynajmniej będzie lekki zysk na wydajności.

JDBC to rozwiązanie nisko poziomowe, zatem będzie z natury szybsze. poza tym Entity Manager nie jest thread-safety, trzeba cały czas pobierać nową instancję (właściwie to Spring robi to za nas, repo ma proxy, które ciągnie nowego EM z EMF) i to trochę przerost formy nad treścią skoro chcesz korzystać ze zwykłych natywek :) Ponadto JPA validuje zapytania w runtime za każdym razem, a JDBC strzela je bez sprawdzania - dałeś d**y - Twoja strata, on jest tylko robolem.

Oczywiście JDBC jest szybsze do momentu, aż nie skonfigurujesz poprawnie cache w JPA i nie zaczniesz wykorzystywać innych featurów. Pomijam już kwestię tego, że użycie JDBC wymaga samodzielnego napisania całkiem dużej ilości kodu, który zapewne będzie mało wydajny i trudny w utrzymaniu... no ale co kto lubi...

@margor90, jeżeli działasz na WL to masz JPA "out of box" i Spring nie jest konieczny. Trochę niepokoi mnie mówienie o braku encji i wykonywaniu natywnych zapytań, bo pachnie to na kilometr powtórzeniami dużych partii kodu. Szczególnie, że tworzenie encji (klas) jest stosunkowo proste, tak samo ich odwzorowywanie na widoki co eliminuje konieczność przechowywania zapytań w kodzie java/znacząco je uprasza.

@Koziołek: pracuje już z istniejącą bazą do programu MapViewer. Mógłbym odwzorować takie tabele, ale wymagałoby to mapowania obiektów Oracle (specjalne obiektowe typy danych) odpowiadających współrzędnym, domyślnie widzi je jako BLOB (chyba, że potworzyłbym widok i mapował go na encje), a chyba nie będzie takiej potrzeby (więcej roboty jak korzyści na etapie prototypowania). To jest na razie prototyp, jak trzeba będzie utworzy się encje. Tyle, że tabele są dość nietypowe np. niektóre nie mają typowego PK (musiałbym to obejść za pomocą @Embeddable). To dopiero proof-of-concept: czy wszystkie technologie się ładnie spinają.

Jak będę pisał właściwą aplikację to się już będę martwił, aby nie było powtórzeń.

Dzięki za potwierdzenie.

Sorry, ale niektóre nie mają typowego PK (musiałbym to obejść za pomocą @Embeddable) jest słabe... Szczególnie, że podział klasy jest dość prostą refaktoryzacją, którą wspierają wszystkie popularne IDE.

te bez typowych PK nie mozesz obejsc jakims many to many, nie tworzyc encji w ogole, albo cos w ten deseń?