Spring i baza JPA2 dla aplikacji desktopowej?

Witam,
Chcę napisać aplikację desktopową i przy okazji wprawić się w IoC (używane częściej w internetowych). Czy Spring nada się, czy też wygodniej będzie poszukać innego narzędzia?

Drugą sprawą jest baza danych: pomyślałem o HSQL ze względu na natywność w stosunku do JVM. Czy ta baza nadaje się do aplikacji desktopowej, nie mam zamiaru uruchamiać dodatkowego serwera i nie chcę się naprawcować przy konfiguracji. Myślę, że fajnie byłoby nauczyć się szablonu upraszczającego JDBC Springa. Pytanie, czy zadziała bez tomcata?

Pzdr.

1. Jak najbardziej się nada, bo i czemu nie?
2. Można spokojnie użyć HSQL, bo to jest baza plikowa. Ona nie wymaga żadnego serwera ani nic. Podajesz tylko lokalizację pliku na dysku i voila. Ale licz się z tym że HSQL dopuszcza max 1 połączenie na raz.

Spring jest OK. Choć osobiście wolę Guice (jest IMO prostszy i bardziej zrozumiały szczególnie na początku i w przypadku aplikacji desktopowych). Co do bazy to pamiętaj, że może być to dowolna baza, ale w przypadku JPA2 ważniejszy jest provider, czyli biblioteka zawierająca implementację standardu. Tu do wyboru masz tak naprawdę dwa rozwiązania - Hibernate i TopLink (EclipseLink). Mają największy, ilościowo, zasób tutoriali i wsparcie comminity w sieci.

Doszedłem do wniosku, że skoro uczę się Springa, będzie iść w Springa i jednak poćwiczyć zapytania JDBC (Spring template), bo JPA i tak często będę używał pisząc aplikacje internetowe.

Dzięki za polecenie alternatywnego IoC, kiedyś pewnie go użyję (bo teraz moim celem jest poznanie popularnych rozwiązań, jak przekroczę powien poziom to będę się zastanawiać jak coś zrobić lepiej).

Wiesz że Spring nie zaleca korzystania z tych templatów? Na pewno z Hibernate template nie zaleca ;] Sprawdź ;]
Oprócz Guice masz też Pico i Nano jeśli chodzi o alternatywne IoC. Te dwa ostatnie w przeciwieństwie do Springa i Guice są ultra lekkie (ale też mocno ograniczone)

Znalazlem taki artykul, ale wciaz nie rozumiem co zlego w szablonach JDBC (poza tym, ze to tak naprawde niepotrzebny narzut na obsluge wyjatku, co mozna zrobic bez szablonu).
http://blog.springsource.org/2007/06/26/so-should-you-still-use-springs-hibernatetemplate-andor-jpatemplate/

Wziolem do reki "Spring w Akcji 3" wyd. Helion. I tam pisza, ze "W wersji 3 zrezygnowano z obslugi starszych wersji Javy. Dlatego nie ma dzis praktycznie zadnego powodu, aby uzywac zwyklego JdbcTemplate zamiast SimpleJdbcTemplate." I dalej omawiaja SimpleJdbcTempalate.

Co wlasciwie zlego w SimpleJdbcTeemplate, skoro polecaja to argumentujac "ze ogranicza spaghetti code / nudne laczenie / lapanie wyjatkow" w dosc aktualnym podreczniku?

No między innymi ten narzut, który nic nie wnosi. Generalnie niepotrzebna warstwa.

BTW dlaczego "direct" SQL w javie jest zły jak masz możliwość wykorzystania JPA:

select ...
from a,b
where a.id=b.id(+)

A następnie migruj z Oracle na np. MySql.

Rozumiem korzysci z uzywania JPA, ze to latwiejsze do migracji itp. Ale mimo wszystko ta technologia wydaje mi sie nieco za gruba na aplikacje, ktora nie ma dzialac na serwerze aplikacyjnym, a byc po prostu JARem odpalanym na desktopie. W zasadzie moglbym olac JDBC, podlaczyc EclipseLink i robic zapytania z uzyciem JPQL/Criteria Queries, a nawet native jakbym sie uparl. I tez by dzialalo, ale jednak intuicja podpowiada ze to troche armata na muche.

Nie mam za duzo komercyjnego doswiadczenia, ale wydaje mi sie, ze JDBC jest w sumie w sam raz do obslugi baz pokroju SQLite'a/HSQL, a czesto takich uzywa sie w nieduzych aplikacjach desktopowych. Ale moge sie mylic. A zdaje sie, ze DataSource Springa moze miec pozytywny wplyw na wydajnosc, poniewaz dzieki temu podlacze sie raz, a w JDBC musze po pierwsze co chwile lapac wyjaki, a po drugie laczyc sie, chyba ze sie myle?

Pzdr.

Zamiast fafakowac to napisz ten przykladowy SQL 'po ludzku' (toz to left outer join <tak, left>) - i co, juz nagle nie trzeba sie meczyc z portowaniem. Wiekszosc aplikacji o jakie pytania tutaj na forum da sie napisac tak, ze SQL bedzie dzialal bez problemow na bazach ktore wspieraja standardy.
Jesli piszesz jeszcze takie plusiki to albo jestes niereformowalnym dinozaurem, albo cwaniakiem chcacym sie wykazac wiedza w glupi sposob.

@autor - nie daj sie namawiac na JPA czy inne takie do wszystkiego. Sa aplikacje, i to wiele, ktore zdecydowanie nie potrzebuja JPA. Koziolek ma dlugo 'track record' polecania armaty na muche, juz baaardzo dawno widzialem rozne takie wpisy. Rozsadek przede wszystkim. Moze u Ciebie faktycznie to jest potrzebne, nie wiem, ale na pewno nie jest to zloty srodek do wszystkiego. Aplikacja ktora ma miec 3 selecty i 1 insert na krzyz bez komplikacji JPA sie obejdzie i wyjdzie na tym lepiej, bedzie szczuplejsza, bedziesz mial wieksza kontrole i mniej komplikacji.

@Shalom - Spring nie zaleza uzywania HibernateTemplate/JPATemplate, bo twierdza ze natywne API jest lepsze. Natomiast JdbcTemplate mowi:

This is the central class in the JDBC core package.

Nie mieszac, myslec, czytac, rozumiec.

SQL jest fajny. Zgadza się. Czy JPA jest wyciąganiem "armaty" na muchę? Raczej nie, ponieważ jest po prostu trochę innym podejściem do problemu. W najprostszej wersji konfiguracja providera JPA ogranicza się mniej więcej do tego samego co konfiguracja JDBC (zakładając, że nie zaszywamy danych bezpośrednio w kodzie). Tworzysz jakiś plik z danymi DB i tyle. Potem w aplikacji użerasz się z sesją takiego lub innego typu. Na pewno JPA jest wygodniejsze jeżeli chcesz wyświetlać dane, odpada zabawa z przemapowaniem wyników zapytania na to co będzie wyświetlone. Wrzucasz zwykły bean pobrany przez JPA do komponentu i gotowe. "Się samo wyświetla".