Newsgroup: it.comp.java
Titolo: Persistenza... quale è la strada migliore ?

Salve a tutti.
Essendo un fan degli OPF (ma in altri linguaggi/ambienti) vorrei sapere quale č il framework di
persistenza piů usato (a ragione o no) in Java.
La mia persistenza deve poter avvenire tanto su file XML che su RDBMS con relativo driver JDBC.
Documentandomi, ho visto che sun ha prodotto le specifiche JDO che alcuni framweork (anche OS)
implementano. Poi ho visto Hibernate, che sembra stabile/usato/maturo ma credo che utilizzi
un *suo* siatema per persistere gli oggetti (tramite la RTTI). Poi ancora c'č Castor di
ExoLab, Torque e OJB di Apache... insomma la valutazione di *tutti* mi richiederebbe
davvero troppo tempo :-(
Un consiglio da chi li ha usati sul campo?
Grazie a tutti
--
Daniele Teti
Software Architect
http://dade2000.altervista.org
 (Home of Message Master for Delphi)

 Un consiglio da chi li ha usati sul campo?
Io spero che gli Entity 3, mettano tutti d'accordo.
E' importante che si converga al + presto su una soluzione unica, perche'
questa frammentazione ci fa perdere molt terreno che avevamo di vantaggio da
.Net.
NEgli anni passati abbiamo infatgti guadagnato molto su di loro proprio
grazie agli App Server, al J2ee, agli EJB che ceercano di dare una soluzione
Aziendale Standard e avanzata
Se non sbaglio si possono gia' usare bene , anche se non sono ancor ain
release
Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 release
Quindi difficilmente li troverei in un progetto "in-essere"?
Riguardo al presente (che vogliamo divenga passato) verso cosa mi converrebbe orientarmi?
Grazie
Daniele

 .Net.
Concordo pienamente. Riguardo alla scelta sul presente finora io, pur 
avendo visto molti persistence layer, non ho mai fatto una scelta 
definitiva (o meglio me ne son costruito uno io :P), non tanto perché 
non mi piacessero (hibernate p.e. mi piace molto), ma proprio per il 
timore di legare un progetto ad una tecnologia non standard e in quanto 
tale passibile di morte prematura e/o abbandono da parte delle sh.
Finora una buona gerarchia di classi, JDBC e un po' di pattern mi hanno 
permesso di navigare tranquillo; quando ci sarà (come spero) *la* 
soluzione definitiva non vedrò l'ora di saltarci dentro :)
-- 
_ _ _  _  /_
  _ /_//_///_' ___
   / and yet it does move...

 Daniele
Ciauz


 soluzione definitiva non vedrò l'ora di saltarci dentro :)
Concordo!
Daniele

 Un consiglio da chi li ha usati sul campo?
Hibernate sembra, al momento, molto popolare.
Io preferisco Cayenne.
Altrimenti puoi provare EOF incluso in WebObjects, ma e' a pagamento.
Ciao
Mirko

 Altrimenti puoi provare EOF incluso in WebObjects, ma e' a pagamento.
Mi documenterň.
Grazie

 soluzione definitiva non vedrò l'ora di saltarci dentro :)
Mi conforta il fatto che c'è qualcun altro che ha seguito la mia stessa
strada :-). In azienda ci siamo scritti un framework di persistenza basato
su ejb session. Spero anch'io che EJB 3.0 (ma per avere appserver
"professionali" che li supportino IMHO ci vorrà almeno un annetto e mezzo)
metterà tutti d'accordo...
Scorpio.

 Ti consiglio Hibernate, a patto che il DB sia fatto a..."modino".
Fai fare il db ad hibernate e sei in una botte de ferro he he
basta che ragioni che hibernarte "E'" il db
Nicola


 metterà tutti d'accordo...
Tra l'altro una risorsa troppo importante è il tempo. Se lavori da solo 
e devi skillarti su qualcosa sei costretto a valutare accuratamente dove 
investire questa risorsa: nell'ottica della "durata" nel tempo del mio 
codice preferisco seguire la "strada maestra" piuttosto che i vicoletti, 
trovandomi magari meno supportato sotto certi aspetti ma sicuramente più 
pronto a "rientrare in carreggiata" al momento opportuno.
Certo, quando non lavoro da solo e c'è l'opportunità di spaziare certi 
vicoletti son davvero belli da esplorare :)


 *evolute* sul db.
Beh, di fatto questo č un "problema" comune a tutti i persistence layer, 
risolto in modo piů o meno evoluto a seconda dei casi ma sempre con una 
sorta di linguaggio proprietario o con "classi di interrogazione". A 
questo punto, dico io, tanto vale conoscere bene SQL e JDBC e poter fare 
tutto piuttosto che conoscere altrettanto bene un linguaggio 
proprietario e poter fare *quasi* tutto.
Il tutto, ovviamente, assolutamente IMHO e rivalutabile da caso a caso :)


 Il tutto, ovviamente, assolutamente IMHO e rivalutabile da caso a caso :)
Perfettamente daccordo!
Daniele

 vicoletti son davvero belli da esplorare :)
Concordo pienamente. Hybernate, JDO etc sono frameworks interessantissimi,
configurabilissimi, belli quanto si vuole ma occorre studiarli, per poi
legarsi ad una soluzione che non è "benedetta" dalla Sun. Se si guarda ad
EJB 3.0, si vede chiaramente che Sun ha accolto numerossissime istanze
"piovute" dai vari progetti opensource, soprattutto volti ad innovare gli
EJB di tipo entity....... questo significa che, per quanto la conoscenza di
framework alternativi sia importantissima, chi ha usato un framework di
persistenza scritto da terzi si trova nelle stesse condizioni, o quasi, di
chi si è mappato a manina via JDBC dei DataObject, al confronto del nuovo
motore di persistenza degli EJB 3.0.
Scorpio.

 E pure tu ci hai raggione,ma non sempre e' possibile...purtroppo...
Se intendi dire che a volte si lavora con db gia' fatti, cosa piuttosto
frerquente, e' vero
Altrimenti se e' fatto bene l'xml IN TEORIA si dovrebbe riuscire sempre,
facendo il file "a modino"
ciao Nicola


 
http://dade2000.altervista.org
 (Home of Message Master for Delphi)
miaooo maks.

 Un consiglio da chi li ha usati sul campo?
- Castor per certe cose e' veramente lento (Quasi fattore 100 rispetto a
Hibernate !), inolte mi pare poco sviluppato e ai tempi avevo problemi
con le date e Oracle.
- Hibernate e' forse l'alternativa migliore. Veloce, completo, con una
vasta community. E' forse un pochino piu' ostico da imparare all'inizio.
- Torque e' ancora "immaturo" se paragonato a Hibernate, ma essendo un
progetto apache potrebbe risultare "vincitore" fra qualche anno.
Io ti consiglierei Hibernate.
-- 
Giambo - Occhio al filtro antispam _e_ alla whitelist !

 Un consiglio da chi li ha usati sul campo?
imho non esiste una soluzione valida per tutto, ma devi decidere in base
alle tue necessità e tante volte conviene farsi tutto a mano per questi
framework non sempre ti semplificano il lavoro...
-- 
Davide Consonni
http://csvtosql.sourceforge.net

 facendo il file "a modino"
Guarda, per la mia breve esperienza ho visto che l'unica cosa che
sarebbe da evitare come la peste, sono le chiavi naturali, o meglio
composte.
Infatti ho istruito a dovere la persona che lavora con me :P
-- 
Q:  What do you call a person who hacks while wearing no clothes?
A:  A gnudist.
Per scrivermi in privato sostituisci cippi...etc con poc punto it
Now riding on Kawasaki Z750 "Black Mamba"

 Infatti ho istruito a dovere la persona che lavora con me :P
intendi chiavi doppie o + ?
se si
peccato perche se metti un id in ogni tabella degradi la leggibilita', togli
valore reale alla chiava, spesso perdi contenuto informativo, talvolta
degrada addirittura la forma normale e altre volte non riesci a togliere
tutti i cicli
N
P.S.
Anche io sono semi niubbo e come inizio mi sta gustando


 togliere tutti i cicli
da hibernat faq:
Does Hibernate support composite keys?
Absolutely. All Hibernate 3.0 functionality works just as well for data
models with natural keys (including composite keys) as it does for models
with surrogate keys.


  Grazie a tutti
Le vostre considerazioni generali sono condivise anche da me.
E' interessante che hibernate 3 supporti le chiavi multiple e non ti
obblighi a sparpagliare sul db vari ID senza significato...
Probabilmente sceglierň hibernate.
Grazie a tutti per l'attenzione.


 obblighi a sparpagliare sul db vari ID senza significato...
Questo e' vero per pochi.
Se il db lo fa un altro al 99% usa gli id.
Quando lo faccio io, e lo riempio di chiavi multiple come piace a me
Gli informatici stessi si lamentano spesso e volentieri, e mi e' capitato
anche che esplicitamente o implicitamente dicessero che non sono capace, e
che con un id per tabella e' tutto + pulito !
Purtroppo ci sono addirittura delle scuole e dei testi che suggeriscono
questa strada.
Mi pare che una e' addirittura pubblicato dalla MS Press, quei raffinati
esteti della progettazione.
Nicola
Pensa te.


 esteti della progettazione.
no comment! M$ č us-dollar oriented!!! Farebbero di tutto per monopizzare il mondo informatico con
tecnologie e *visioni* proprietarie dello stesso!
Alla faccia degli standard e del buon senso!
Ciao Daniele

 Mi daresti delle motivazioni?
Mi piace?
Io uso da una decina d'anni la tecnologia NeXT e conoscendone pregi e 
difetti la preferisco a molte altre soluzioni. Il loro ambiente di 
sviluppo era gia' al tempo avanti dieci anni rispetto ai concorrenti ma 
non hanno avuto molta fortuna...
Nel '96 potevi costruire un'applicazione web a componenti in modo 
simile, ma diverso, a quel che puoi fare oggi con Tapestry, potevi 
prendere un'applicazione desktop ed in poco tempo scriverci un frontend 
web. Per quanto riguarda la persistenza degli oggetti sono partiti dal 
DBKit -> EOF1 -> EOF2/3 al tempo c'era TopLink for Smalltalk di Object 
People.
Con EOF migrare da un db ad un altro era una lavoro abbastanza semplice.
Al tempo si scrivevano cgi in c/perl/sh, pagine php, asp, jsp ecc ecc.
Cayenne non e' uguale ad EOF ma simile. Il bello e' il supporto su 
mailing list e dall'autore.
Quando ho avuto problemi per inesperienza o carenza di documentazione 
in un giorno ho sempre ricevuto la soluzione. (usata da 1.0 in beta)
Se devi mettere mani ai sorgenti del framework puoi farlo benissimo 
senza impazzire.
Chiaro che se ti serve una feature particolare puo' risultare di non 
semplice soluzione.
(con Cayenne come con altri)
Qui trovi qualche recensione/discussione:
http://www.theserverside.com/blogs/showblog.tss?id=CayenneAndHibernate
http://theserverside.com/articles/article.tss?l=Cayenne
http://www.theserverside.com/news/thread.tss?thread_id=26498
http://theserverside.com/news/thread.tss?thread_id=26325
Ciao
Mirko

> legarsi ad una soluzione che non è "benedetta" dalla Sun.
Benedetta o meno, hibernate è la soluzione.
Prima che EJB 3 funzioni decentemente passerà tempo. Sperando che non siano
l'ennesimo flop.
Hibernate funziona, è gratuito ed è adottato largamente.
Luigi