Newsgroup: it.comp.java
Titolo: ORM o JDBC?

Ciao a tutti,
vorrei un vostro parere riguardo l'utilizzo di ORM in applicazioni web
sviluppate con GWT. Sto un pò ricredendomi riguardo gli ORM, e mi
domando se valga effettivamente la pena di utilizzarli in applicazioni
web sviluppate con GWT. Quali sarebbero i reali vantaggi oltre alla
maggiore indipendenza e portabilità?
Aspetto i vostri commenti :)

 maggiore indipendenza e portabilità?
orm significa in soldoni mappare i dati come entity java, se questo non lo
vedi come vantaggio...
-- 
from iPad

Mia personalissima opinione:
Svantaggi degli ORM:
+ complessit�
+ dipendenza dall'esterno
- flessibilit�
Vantaggi:
facilit� di programmazione (???)
Ciao
Franco
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.francolombardo.net
Scala, Java, As400.....
http://twitter.com/f_lombardo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 


Velocità nello sviluppo, ad esempio; è innegabile che con gli ORM puoi 
realizzare la gran parte dello strato di accesso al database in poco 
tempo, almeno rispetto a doversi scrivere tutte le query e il codice di 
mapping.
Inoltre:
- non sei mica obbligato ad avere per forza di cose dei mapping assurdi 
e complicatissimi solo perché "è cool avere una relazione ternaria 
mappata da un'entity" (è solo un esempio);
- c'è più o meno sempre una scappatoia per poter utilizzare SQL 
direttamente.
My 2c
-- 
Dimitri De Franciscis
Phone:  
(+39) 3401570778
Website: 
http://www.megadix.it/

 + complessità
ma anche no.
mappare un entity con le annotation e' estremamente semplice.
caricare un record o fare una select e' una riga di codice.
il codice risultante e' molto piu' leggibile e manutenibile.
le cose si complicano solo quando entri nei casi veramente particolari.

 le cose si complicano solo quando entri nei casi veramente particolari.
I casi particolari, nella mia esperienza, sono moooolto frequenti in 
applicazioni mediamente complesse.
D'altra parte, se l'applicazione � semplice, non so se valga la pena di 
usare un ORM ;-)


 usare un ORM ;-)
assolutamente.
mai piu' senza.
le volte che mi ritrovo ad usare il jdbc secco sono perso.

Grazie per i vostri interventi.
Sicuramente gli ORM hanno i loro vantaggi, ma credo che introducano
anche una maggiore complessità, ed in caso di problemi si perde
parecchio tempo nel debugging e nel tuning.
Quindi, in definitiva, suggerireste l'utilizzo di ORM per il backend
di applicazioni GWT di piccole-medie dimensioni? Se si, quale? Vedo
che Hibernate è ancora molto diffuso, ma non mi piace l'idea di dover
avere un file XML per ogni entità...

 avere un file XML per ogni entità...
Ti suggerisco questa discussione su stackoverflow:
http://stackoverflow.com/questions/452385/what-java-orm-do-you-prefer-and-why
Tratta in modo più approfondito gli argomenti discussi qui e segnala 
vari ORM meno "famosi" ma decisamente validi (SimpleORM, ActiveObjects, 
etc.).


Non devi avere alcun file XML per entità. Suvvia siamo nel 2011 e le 
annotazioni sono state introdotte parecchi anni fa.

 facilità di programmazione (???)
+ performance in applicazioni complesse.

Non mi pare che con GWT hai altre opzioni se non utilizzare il loro ORM per 
via del Cloud.
"carmelo"  wrote in message 
news:f7d9e307-fbeb-4700...@e21g2000yqe.googlegroups.com...



Credo si intenda maggior complessità architetturale..
Usare un ORM vuol dire avere un pezzo in più da gestire e che si può
rompere...
Poi bisogna impararlo moooolto bene... E non e che di contro
dimentichi come funzionano i db...


Beh, ma tra ORM e jdbc puro ci sono tantissime vie in mezzo...
Una buona strategia e quella di scrivere una libreria che legge le
query da file e le esegue come prepare statement..
Nel 2003 ho realizzato questa, e un Po vecchiotta, oggi probabilmente
la scriverei in un altro modo... ma lavora alla grande...
code.google.com/p/sqlrepository


Attento che con le annotation non hai più questo problema... Non hai
più XML se non uno x gestire connessioni e il package da cercare...

 facilit di programmazione (???)
Ormai sono 5 anni che lavoro con vari ORM.
Purtroppo non sono così convinto che hai maggiore facilita' nella
programmazione...
Non sempre hai la necessita' di estrarre tutti i dati da una tabella,
magari una volta ti serve una relazione, un'altra volta no...
Hai spesso, per un'entity, differenti modalità di interrogazione
reali. Con Hibernate o uno degli altri ORM JPA like, sei portato a
dover definire un modello comune a cose che per propria natura non lo
sono..
Ti faccio un esempio:
Entita' Azienda, Entita' Utenti.
Legati da sinistra a destra con una one to many, mentre da destra a
sinistra con una many to one.
Nella gestione utenti dell'amministratore ha la necessita' di sapere
qual'e' l'azienda legata all'utente, e fin qui OK.
Quando un utente gestisce il proprio profilo, tipo per cambiare la
password, hibernate mi estrae comunque i dati dell'azienda associata,
anche se in questo caso non mi serve una mazza. In alcune applicazioni
l'utente non sa nemmeno che il programma gestisce piu' aziende...
Con le JSP e simili non è un grave problema. Quando pero' hai a che
fare con un'applicazione tipo Web Service, i problemi li hai eccome,
perché i dati che hai estratto da DB, vengono serializzati e sparati
su rete, rallentando l'applicazione, alle volte con piu' di un ordine
di grandezza, perche' le relazioni possono essere piu' o meno corpose.
Per risolvere il problema sei quindi costretto a creare un oggetto
wrapper, che venga serializzato solo nelle componenti che ti
occorrono.
Pensiamo invece di usare JDBC standard, con magari qualche aiuto.
Eseguo una query, la scrivo certo, i dati estratti li serializzo cosi'
come sono, senza ragionamenti.
Se ho altre necessita', eseguo una query piu' appropriata ed ho solo i
dati che mi servono.
Gli ORM JAVA sono davvero troppo rigidi, almeno per come concepisco io
il modo di sviluppare.
Speriamo nella nuova notazione per mappe e liste, con java 7, per
avere un po' piu' di flessibilita'.
Ciao, Davide.

 il modo di sviluppare.
Anche con gli ORM puoi fare queries (jpql e, nei casi di estrema necessita' anche sql), e queste possono tornare oggetti legati al tuo modello, oppure completamente slegati da esso (quest'ultima soluzione non ha molto senso, ma e' comunque una possibilita'). 
-- 
SoulSpirit

 l'utente non sa nemmeno che il programma gestisce piu' aziende...
Non è neccessariamente vero, infatti è possibile rendere lazy anche le 
one-to-one e many-to-one tramite instrumentazione del bytecode (tramite 
semplice annotation e un task ant).

 Anche con gli ORM puoi fare queries (jpql e, nei casi di estrema necessita' anche sql), e queste possono tornare oggetti legati al tuo modello, oppure completamente slegati da esso (quest'ultima soluzione non ha molto senso, ma e' comunque una possibilita').
Adesso lo so che parte un flame e mi insulterete tutti :)
Il fatto che tu lo possa fare è fuori discussione, il fatto che sia
semplice farlo è purtroppo un altro paio di maniche...
Guarda ad esempio Ruby, con active records puoi, una volta estratti i
dati, eliminare colonne, aggiungerne, puoi manipolare come ti pare il
dominio dei dati. Il tutto usando sempre gli stessi metodi.
Non hai la modalita' "fichissima" per la navigazione degli oggetti e
la scappatoia nativa per le cose complesse, ma con lo stesso
strumento, in modo naturale fai tutto... Allora si che un ORM è
comodo, pratico e facile da usare...
In java purtroppo non e' cosi', ma non lo e' per via della natura
statica del linguaggio java.. percui, finche' creare un oggetto
significa scrivere una classe, e' ovvio che non sara' mai
flessibile...
Sono certo che con il nuovo supporto alle collections di java 1.7, le
cose cambieranno in meglio...
Ciao, Davide.


Fico... in che modo???


Aspetta, ma dici a runtime? Non credo, il mapping viene letto
all'avvio, a meno di forzare un reload...

 semplice annotation e un task ant).
Questo non fa altro che confermare la mia tesi: gli ORM aumentano la 
complessità. Per ogni singolo problema devi introdurre una pezza che ne 
introduce altri 10.
Ad un incontro dell'XP User group di Milano un collega entusiasta di 
Hibernate che mi ha lasciato di stucco con la frase "Uso Spring per 
risolvere i problemi di Hibernate".....
Ciao
Franco
-- 


 risolvere i problemi di Hibernate".....
Forse perchè il tizio è rimasto un tantino indietro. Quali problemi 
risolverebbe Spring? In realtà gli sviluppatori di Hibernate negano 
fortemente questa necessità ed anzi in passato hanno fortemente 
sconsigliato l'utilizzo di alcune classi di supporto fornite da Spring 
(HibernateTemplate ad esempio).
Io uso EJB3 con Hibernate dietro interfacce JPA, e per quanto mi 
riguarda il modello che mi offre è eccellente.

 risolvere i problemi di Hibernate".....
Ammazza, che brutta gente che conosci :)
Mi ricordo quella frase, il ristorante cinese e tutto il resto, ma non
pensavo che due parole dette dopo qualche birretta potessero essere
preso come esempio mesi dopo sul newsgroup...
Se lo sapevo ci ragionavo meglio :D Pensa che tutte le volte che vedo
Mimmo dell'xp, ancora mi prende in giro...
Scherzi a parte, visto che parli di me, mi tocca smentirti, almeno su
un punto, IO NON SONO MAI STATO UN FAN DI HIBERNATE!
Ho sempre sostenuto fortemente che fosse un capitolato troppo pesante
da portarsi dietro nelle applicazioni...
In particolare una delle cose che proprio non digerisco di hibernate
e' l'enorme quantita' di ram che utilizza.
Alla maggior parte degli sviluppatori non importa un tubo, ma ora che
in azienda mi devo occupare anche del "dove installo il mio
applicativo" e del "quanto mi costa quel server", e' un aspetto cui
devo dare per forza molto peso...
Non tutti i clienti sono disposti a spendere un mucchio di quattrini
mensili solo per la voce RAM in fattura.
Hibernate e spring, insieme poi, sono proprio un'accoppiata vincente
in tal senso... Non c'e' verso di far si che usino meno di 300Mb di
RAM, gia' allo startup.
Ma poi per avere quale vantaggio??? Si, hai oggetti invece che
resultset, ma basta una libreria di pochi kb per gestirti connessioni
e serializzazione dei dati e le query te le scrivi tu...
Questo e' un vantaggio, non un problema...
Se la scrivi tu la query, poi puoi ottimizzarla o meglio, la fai
ottimizzare a chi per mestiere fa solo quello.
Con hibernate puoi scrivere le query native, ma non è lo stesso, devi
comunque intervenire nel codice, perche' sono comunque due metodi
differenti.
Dal mio punto di vista hibernate e' un pezzo in piu' che si puo'
rompere nella tua applicazione.
Spring lo stesso cinema, fa cose anche interessanti, vero, ma sono
piu' i problemi che introduce che quelli che risolve...
Ma dai, non vi e' mai capitato di dover debuggare pezzi di codice
spring o hibernate, per verificare quello che si rompe??
Poi ne vieni a capo, certo, ma appena ti scosti di un byte da quello
che era stato pensato dagli sviluppatori, non va piu' un tubo...
Sono strumenti fragili, che ti danno solo la parvenza di sicurezza,
con complessi meccanismi di validazione, per rassicurarti che se il
dominio dei dati cambia, non va piu' un tubo..
E' come impilare un mucchio di libri, ognuno con larghezza e peso
differente. Prima o poi, ad aggiungerli alla pila, il mucchio cade.
Wow, mi sento come piu' leggero ora :)
Ciao, Davide.

 ottimizzare a chi per mestiere fa solo quello.
Ci vorrebbe il pulsante "Mi piace" anche su Usenet :)

 collegati a questo fatto.
Scusa, una domanda, io ho una relazione, devo cambiare, solo per una
determinata funzionalita' del mio servizio, il fetch type da lazy ad
eigher.
Per fare questo, devo configurare un task ant??? Ma sono il solo a
trovare la cosa allucinante?
Per estrarre i dati in join o in lazy, devo chiamare un task ant! Che
nesso hanno le due cose?
Come se per chiamare un particolare numero di cellulare, avessi
bisogno della segretaria che mi compone il numero, perche' io non sono
capace da solo...
Assurdo.


:)

 nesso hanno le due cose?
adesso io non so bene cosa intenda cicap ma:
class Group {
 @OneToMany(fetch = FetchType.LAZY)
 private Set<Product> products;
}
e poi:
from Group g inner join fetch g.products
non fa altro che forzare il fetch eager del onetomany
mentre
from Group g 
mantiene il fetch lazy dato in annotationfe
senza ant, bytecode e cazzi vari
http://docs.jboss.org/hibernate/core/3.3/reference/en/html/queryhql.html
"A "fetch" join allows associations or collections of values to be 
initialized along with their parent objects using a single select. This 
is particularly useful in the case of a collection. It effectively 
overrides the outer join and lazy declarations of the mapping file for 
associations and collections."

 Ammazza, che brutta gente che conosci :)
No, anzi, discutere con te e con tutti gli amici di Milano è sempre un 
piacere!
Riguardo alla frase, scusa ma è stata veramente TROPPO mitica!!!!
:-)


 trovare la cosa allucinante?
No, si parlava di rendere lazy cose come @OneToOne, @ManyToOne.
Per il problema che hai posto non c'č nessun task da configurare, anzi 
il comportamento lazy č quello di default.
-- 
Non č affatto cosě. Ne sono certissima. (Angelis)
In *sequenza* hai: sputato dentro il piatto dove hai mangiato
  per tre mesi, e *contemporanemente*, svilito te stesso. (Angelis)

 ottimizzare a chi per mestiere fa solo quello.
Chi scrive query utilizzando HQL (il linguaggio di Hibernate) deve 
necessariamente conoscere bene l'SQL. E sa benissimo quale SQL sta 
producendo e se vale la pena inizializzare quell'associazione o meno.


 che era stato pensato dagli sviluppatori, non va piu' un tubo...
Io mi scosto spesso (e volentieri :) ) da quello che tipicamente è 
l'utilizzo tipico si Spring e Hibernate (guarda ad esempio come funziona 
il mio Lambico 
www.lambico.org
), ma non mi pare che non funzioni "più un 
tubo".
Ciao
   Lucio
-- 
Lucio Benfante       
http://www.lambico.org
JUG Padova           
http://www.parancoe.org
www.jugpadova.it
 
http://www.jugevents.org


Questa e' una soluzione! Lo script ant, sembra piu' quando TOM
costruisce trappole assurde per intrappolare Jerry... Tipo che col
tostapane fa scattare un elastico, che colpisce una biglia, etc...

> Tu credi di essere un genio in un mondo di cretini per caso?
Un post con questi toni, a mio avviso, non merita risposta.

 tubo".
Caspita, questa si che e' una cosa davvero carina!
Vedi Lucio, ci sono sempre mille strade, l'importante e' cercare di
fare le cose per bene e in tutto ci sono pro e contro...
Ho parlato di due applicazioni, un'amministrazione ed un Web. Nella
prima la scelta di hibernate e' stata fatta perche' l'applicazione e'
molto strutturata e ricca di logica. Hibernate tornava comodo,
gestisce le relazioni. Nella seconda invece ci sono poche query, ma
molto performanti, uno strato di presentazione molto articolato,
hibernate era una grossa limitazione ed abbiamo preferito
un'architettura piu' snella.
Io hibernate e spring non li amo, e' vero, spesso pero' sono costretto
ad utilizzarli! Non lavoro da solo grazie al cielo e bisogna spesso
scendere a compromessi...
Ci sono colleghi che con hibernate danno il meglio di se e che quando
scrivono una query, gli viene da piangere.. altri che vorrebbero
scrivere solo in ruby, perche' il resto e' una schifezza...
Ciao, Davide.

 Questa e' una soluzione! Lo script ant,
Lasciatelo dire: non hai capito nulla.
Invece ti sparare cazzate a raffica, sarebbe meglio se tu spendessi 
qualche minuto a leggere attentamente le risposte. Magari ci scappa che 
impari qualcosa, chi lo sa.

 casi possibili...
Ancora con sta menata. Davvero la tua applicazione è composta *in gran 
parte* da query diverse dal solito
select a from A a left join B b where ...
? No perchè queste sono più o meno le query che si fanno in un 
applicazione web usuale. Ora spiegaci cosa ci vedi da ottimizzare e le 
diversità che dovrebbero emergere tra Oracle, MySql, ecc...

 scrivere solo in ruby, perche' il resto e' una schifezza...
Dal non amarli...a sconsigliarli fortemente (per una ragione come la 
presunta occupazione di memoria) come hai fatto tu nella mail originale, 
ce n'è di strada. E frasi come "sono più i problemi che introduce", sono 
semplicemente non vere.
Poi in ogni contesto si deve (si dovrebbe, ci piacerebbe...vedi tu) 
scegliere lo strumento migliore per lo scopo da raggiungere, su questo 
non ci piove. Però suggerire l'utilizzo di una libreria di basso livello 
come JDBC (a cui sovrapporre un framework fatto in casa), rispetto ad un 
qualunque altro framework (non necessariamente Hibernate) di più alto 
livello noto e diffuso, è un po' come suggerire di usare l'assembly 
invece che il C perchè il codice prodotto dal compilatore C non è 
abbastanza ottimizzato. Il che è generalmente un pessimo consiglio 
(ovviamente valido in casi molto particolari).
Ciao
   Lucio
-- 
Lucio Benfante
JUG Padova           
http://www.parancoe.org
 ...have a look at it!
www.jugpadova.it
 
http://www.jugevents.org

 da solo ha le sue belle magagne da capire.
Si, ma che gli dai da fare? Non voglio togliere nulla ai tuoi
stagisti, ma se gli dici "realizzami questo progetto web con hibernate
e spring" puoi guidarli quanto vuoi, ma che in due giorni già diano
risultati mi sembra un po' difficile, sia con hibernate che con
JDBC...
A meno che per guidarli non intendi, scrivimi questi pojo... In due
giorni non leggi nemmeno l'indice della documentazione di spring e
hibernate...
Senti poi, non saro' bravo, me ne faro' una ragione, ma ogni volta che
devo mettere in piedi un'architettura con hibernate e spring, ci metto
sempre una vita.. che ti devo dire..
Vorra' dire che un giorno offriro' una birra a te e cicap insieme,
cosi' mi spiegate come si fa a lavorare in modo produttivo...
Io invece vi scrivo una bella query. Basta che la finiamo con sto
thread che ormai e' diventato sterile.

 incomprensibile... Per non parlare dei proxy...
AH AH AH AH AH AH. La perla finale. Almeno per me, visto che mi fermo 
qui inorridito.

 thread che ormai e' diventato sterile.
Sono d'accordo. punto!


Francamente non capisco la ragione percui ve la prendete in questo
modo... mica vi sto insultando (IO), stiamo parlando di codice
ragazzi, trombate un po' di piu', bevetevi una birra, andate a giocare
a pallone...
1. Nessuno ha chiesto a nessun'altro di usare sqlrepository, vecchia,
risale al 2004/2005. Non la sponsorizzo proprio per questo, ovvio che
se la dovessi scrivere adesso, lo farei in un modo totalmente
differente o forse non lo farei proprio... e comunque, in pochi minuti
hai aperto il file, letto come funziona e, senza nemmeno farlo
partire, hai individuato un bug. Prova a modificare hibernate.
2. Il concetto che cerco di esprimere e' che alle volte complicare
l'architettura usando hibernate e spring non serve.
Quello che dite voi e' che hibernate e spring non occupano molta
memoria e non complicano l'architettura, che si imparano in fretta
almeno per quanto riguarda i rudimenti e che quindi sono strumenti da
usare sempre.
Io non sono d'accordo, posso?
3. Per sviluppare (purtroppo) usiamo Hibernate e Spring, ma capitano
situazioni per cui riteniamo piu' opportuno usare una vecchia
libreria, nata quando hibernate non era cosi' scontato, la prassi era
scrivere html nelle servlet e struts 1 era ancora considerato una
buona invenzione.
4. E' gia' capitato di dover tunare una query e chiedere al DBA di
doverlo fare. Sia con hibernate che con query native SQL. Nel primo
caso si deve lavorare in due, nel secondo invece, se la sbriga da
solo. Se non vi e' capitato di aver bisogno di un DBA, forse quelle
applicazioni non sono cosi' grosse come credete..
5. Conosco bene sia hibernate che spring, ma non li amo, e' grave? Se
e' cosi' finiro' all'inferno dei programmatori, costretto in eterno ad
usare un pc con windows ME e scrivere query HQL... Me ne faro' una
ragione.
6. Postate un po di vostro codice di sei anni fa, vediamo se non ci
sono bug.
7. Mi parli di scalare un applicazione? Ma non mi hai risposto... Se
dovessi rifare facebook, useresti java+hibernate+spring? Io non userei
sqlrepository, ma nemmeno hibernate+spring.
Per la cronaca, non sono il solo che non da per scontato l'uso di
hibernate e spring. Play! framework 
http://www.playframework.org/
 ad
esempio non usa ne l'uno ne l'altro e il risultato e' molto buono.
Ora che ci penso, non usa nemmeno maven, che orrore!
Forse che c'e' un piccolo orticello a fianco al vostro che non ne puo'
piu' di standard pesanti come avere i reattori di fukushima sui
maroni?
Io sono uno di quelli e non sono il solo.
Ciao, Davide.

 esempio non usa ne l'uno ne l'altro e il risultato e' molto buono.
Ehm, controlla meglio...
Play usa JPA, prelevando un bel pezzo di Hibernate (vedi packages o 
documentazione).
Esempi alternativi e piů azzeccati ce n'erano molti; simpleorm o 
activeobjects, per dire.
Cosě, solo per impicciarmi un po'... ;-)

 maroni?
Si ma questi signori sono tutti come te? Giusto per sapere.