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,