Newsgroup: it.comp.java
Titolo: Hibernate per applicazione standalone

ciao a tutti
ho cominciato in questi giorni a guardare e provare ad utilizzare un po' 
Hibernate (mi servira' anche in futuro, immagino, per la realizzazione di 
una web application abbastanza grossa..)..
ho notato che, se da un lato fornisce ottimi strumenti per la manipolazione 
dei dati da db, dall'altro e' estremamente lento rispetto alle normali query 
sql..
questo puo' benissimo andar bene in una web application, dove aspettare 3 
secondi per caricare dati in una tabella non e' niente di opprimente.. ma 
per un'applicazione standalone, sviluppata con una gui swing, riempire una 
jTable in qualche secondo e ancora peggio aggiornare dei campi esterni (a 
seconda della riga seleziona nella jTable) in tempi non quasi immediati, e' 
parecchio frustrante..
c'e' qualcosa di simile ma di gran lunga piu' leggero? o ancora meglio, 
hibernate ha senso utilizzato in applicazioni desktop standalone?
se la risposta e' no, cosa posso usare? :) 

 se la risposta e' no, cosa posso usare? :) 
Hibernate non è esattamente uno strumento per semplificare o ottimizzare
le query. La sua forza è nel gestire la persistenza, cosa che non stai 
utilizzando, se ti interessa solo un tool che converta un resultset in 
una collection di bean.

 un resultset in una collection di bean.
no, infatti ho specificato che probabilmente tornera' utile per una web 
application che sviluppero' in futuro..
mi chiedevo pero' se fosse possibile usarlo, ovviamente non sfruttandone 
appieno le potenzialita', per applicazioni desktop, in cui i dati sono 
relativamente pochi e convertire un resultset in una collection di classi e' 
fattibile anche manualmente via sql..
e mi sembra di capire dalla tua risposta che evidentemente non e' 
conveniente utilizzare un framework di persistenza per applicazioni simili..
ma quindi, affrontando direttamente il problema, per riempire delle jtable o 
altri jcomponent con dati provenienti da una base di dati (dati sempre dello 
stesso tipo.. avro' alcuni resultset contente dati di clienti, altri 
contententi dati su alcuni articoli commerciali, etc) il modo migliore e' 
creare delle classi fisse (in questo caso una classe Cliente, una classe 
Articolo, etc) e riempire una collection di classi ad ogni query?
perche' se devo ottenere una row sola e passarla in giro fra moduli (un solo 
oggetto Cliente, per esempio, risultato di un select where id = x, per 
esempio) posso capire che sia il metodo migliore, ma se devo riempire una 
jtable?
e' meglio riempire un array bidimensionale di stringhe? 
(array[rowY][fieldX])
per poi ogni volta che si seleziona una riga dalla jtable effettuare una 
query che crea un oggetto di tipo Cliente e ne mostra le informazioni in 
vari jlabel o jtextfield.. e' il modo migliore per muoversi? 

 c'e' qualcosa di simile ma di gran lunga piu' leggero? 
Se ti va puoi provare ammentos :) La url è in firma.
pole
-- 
ammentos - a lightweight persistence framework for JDK5
http://www.sourceforge.net/projects/ammentos
http://ammentos.biobytes.it


eheh.
Ma lo hai mai usato per applicazioni reali?
E non ho capito se supporta anche la gestione delle relazioni uno a molti e 
molti a molti ad esempio. 

 Se ti va puoi provare ammentos :) La url è in firma.
avevo gia' dato un occhiata, ma il problema su cui in effetti mi ha fatto 
ragionare vincent vega si antepone alla scelta di un framework di 
persistenza :)
provi a guardare la mia risposta al suo post e darmi qualche consiglio sul 
da farsi? 

 molti a molti ad esempio. 
Me lo chiede sempre anche il mio collega col quale spesso affrontiamo 
interessantissime ed estenuanti conversazioni sul design :)
In tutta franchezza però, finora non mi è ancora venuto in mente un 
sistema ottimale (e nemmeno a lui :-)) per gestire le relazioni multiple 
che rimanendo nello spirito del fw semplifichi le cose invece di 
complicarle, tenendo presente la facilità con cui è possibile costruire 
le istanze di query.
Ho visto le soluzioni presenti in alcuni dei più famosi framework, e 
generalmente ho riscontrato soluzioni troppo macchinose o con un pesante 
impatto sul design del database, mentre il mio motto è sempre stato 
"disegna il db, disegna le classi e fai il mapping", ovvero il fw di 
persistenza non deve interferire nel design.
Ciò non toglie che, trattandosi di codice aperto, se qualcuno dovesse 
avere una valida idea, che con una o due annotation risolve il problema 
  sarebbe il benvenuto ;)
Una delle ultime cose che ho sviluppato e che trovo molto utile nella 
gestione delle relazioni multiple sono le liste persistenti. Facendo una 
query al fw tramite il metodo Ammentos.loadUpdatable() (ora mi sovviene 
che non l'ho ancora documentato :-|) si ottiene il riferimento a una 
List di un tipo particolare, i cui metodi add(), remove() etc. sono 
sovrascritti per salvare, cancellare etc. in modo persistente gli 
oggetti inseriti.
Certo se per te non è una soluzione accettabile pazienza, il mare della 
persistenza offre tante altre spiagge ;)



In effetti io uso Hibernate, ma mi recondo conto che uso solo una parte 
della sua potenza.
Il fatto é che Hibernate non mi sembra possa essere usato in modo 
trasparente, perché altrimenti si incappa in una delle sue solite eccezioni 
(ad esempio quella in cui non possono esserci 2 oggetti diversi con lo 
stesso id e classe dentro la stessa session). Oppure lo si può utilizzare in 
modo trasparente ma tralasciando molti dei suoi aspetti.
Ad esempio capita spesso che in una Request carico in sessione (di tomcat) 
un utente che ha una serie di item collegati, e ho inizializzato mettiamo la 
sua collezione per visualizzare questi item dentro una jsp. Poi la volta 
dopo recupero l'utente dalla sessione di tomcat e faccio un bel saveOrUpdate 
per attaccarlo alla sessione di Hibernate. Ecco, questa operazione non può 
essere fatta trasparentemente senza considerare il contesto in cui viene 
fatta, perché se per caso avevo un item caricato da prima attraverso una 
query qualsiasi, hibernate solleva quella maledetta eccezione!
Questo limita di molto la possibilità di chiamare piu' metodi di accesso al 
database in successione.
Forse é meglio che il tujo framework non abbia di queste complicazioni, così 
forse quando ci si accorge che in realtà si sta utilizzando un 1/4 di 
Hibernate, ci si rivolge a un framework più leggero come il tuo!

 da farsi? 
Tenendo conto che io la soluzione "solo sql" la escluderei per progetti 
di più di una o due classi,mi pare che tu abbia sempre bisogno di un 
"qualcosa di simile ad Hibernate ma di gran lunga più leggero".
Una soluzione te l'ho proposta prima; ne trovi molte altre qui:
http://java-source.net/open-source/persistence


 Una soluzione te l'ho proposta prima; ne trovi molte altre qui:
infatti se dovessi utilizzare necessariamente un framework di persistenza 
pensavo proprio di utilizzare il tuo :)

 pensavo proprio di utilizzare il tuo :)
Commenti e critiche sarebbero in tal caso ben accetti :)


 Commenti e critiche sarebbero in tal caso ben accetti :)
subito una domanda, leggendo con il tuo framework non mi e' chiara una 
cosa..
se devo prendere dei dati da un join di due tabelle, come faccio?
devo costruire una classe che contenga i dati del join richiesto e annotarla 
con il sourceDomain="... join ..."? 

 
Esatto, il sourceDomain è il dominio da cui i dati vengono "pescati".
Comunque ti suggerirei di creare una vista invece di scrivere la join 
dentro l'annotation.
NB: il target domain in questo caso andrà specificato diversamente visto 
che ovviamente non può essere una vista o una join.


 visto che ovviamente non può essere una vista o una join.
se non e' un problema, ti mando una mail :) 

 se non e' un problema, ti mando una mail :)  
Nessun problema, ti ho risposto :)


 E' un modo che ha vantaggi e svantaggi. Sta a te poi scegliere.
grazie mille a tutti, mi avete chiarito moltissimo le idee :)