Discussione:
ORM o JDBC?
(troppo vecchio per rispondere)
carmelo
2011-03-23 08:41:06 UTC
Permalink
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 :)
rootkit
2011-03-23 22:01:38 UTC
Permalink
Post by carmelo
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à?
orm significa in soldoni mappare i dati come entity java, se questo non lo
vedi come vantaggio...
--
from iPad
Franco Lombardo
2011-03-24 09:22:11 UTC
Permalink
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
hybris
2011-03-24 09:45:42 UTC
Permalink
Post by Franco Lombardo
+ 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.
Franco Lombardo
2011-03-24 12:01:15 UTC
Permalink
Post by hybris
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 ;-)

Ciao

Franco

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.francolombardo.net
Scala, Java, As400.....
http://twitter.com/f_lombardo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
hybris
2011-03-24 12:50:56 UTC
Permalink
Post by Franco Lombardo
D'altra parte, se l'applicazione è semplice, non so se valga la pena di
usare un ORM ;-)
assolutamente.
mai piu' senza.
le volte che mi ritrovo ad usare il jdbc secco sono perso.
carmelo
2011-03-24 16:14:41 UTC
Permalink
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à...
Pablo
2011-03-24 17:10:33 UTC
Permalink
Post by carmelo
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à...
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.).
cicap
2011-03-24 18:59:01 UTC
Permalink
Post by carmelo
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à...
Non devi avere alcun file XML per entità. Suvvia siamo nel 2011 e le
annotazioni sono state introdotte parecchi anni fa.
Davide
2011-03-29 07:59:32 UTC
Permalink
Post by carmelo
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à...
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...
Davide
2011-03-29 07:57:19 UTC
Permalink
Post by hybris
Post by Franco Lombardo
D'altra parte, se l'applicazione è semplice, non so se valga la pena di
usare un ORM ;-)
assolutamente.
mai piu' senza.
le volte che mi ritrovo ad usare il jdbc secco sono perso.
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
Davide
2011-03-29 07:50:22 UTC
Permalink
Post by hybris
Post by Franco Lombardo
+ 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.
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...
cicap
2011-03-24 19:00:00 UTC
Permalink
Post by Franco Lombardo
+ complessità
+ dipendenza dall'esterno
- flessibilità
facilità di programmazione (???)
+ performance in applicazioni complesse.
Davide
2011-03-29 09:12:54 UTC
Permalink
Post by Franco Lombardo
+ complessit
+ dipendenza dall'esterno
- flessibilit
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.
cicap
2011-03-29 16:59:43 UTC
Permalink
Post by Davide
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...
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).
Davide
2011-03-30 09:10:33 UTC
Permalink
Post by cicap
Post by Davide
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...
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).
Fico... in che modo???
Davide
2011-03-30 09:12:25 UTC
Permalink
Post by Davide
Post by cicap
Post by Davide
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...
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).
Fico... in che modo???
Aspetta, ma dici a runtime? Non credo, il mapping viene letto
all'avvio, a meno di forzare un reload...
Franco Lombardo
2011-03-31 08:44:32 UTC
Permalink
Post by cicap
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).
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
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.francolombardo.net
Scala, Java, As400.....
http://twitter.com/f_lombardo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cicap
2011-03-31 17:33:29 UTC
Permalink
Post by Franco Lombardo
Post by cicap
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).
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.
Mi pare un tantino esagerato, anche perchè difficilmente in pratica
questa limitazione di traduce in un problema.
Primo è molto probabile che tale oggetto associato serva all'interno
della transazione. Secondo esiste una cache di primo livello (ovvero a
livello di transazione) per cui l'oggetto verrà caricato una sola volta
per transazione al massimo. Terzo la complessità per risolvere
totalmente il problema è quella di aggiungere un annotation e
configurare un task ant. Francamente non vedo altri 10 problemi
collegati a questo fatto.
Post by Franco Lombardo
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".....
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.
Davide
2011-04-01 09:42:22 UTC
Permalink
Post by cicap
Mi pare un tantino esagerato, anche perchè difficilmente in pratica
questa limitazione di traduce in un problema.
Primo è molto probabile che tale oggetto associato serva all'interno
della transazione. Secondo esiste una cache di primo livello (ovvero a
livello di transazione) per cui l'oggetto verrà caricato una sola volta
per transazione al massimo. Terzo la complessità per risolvere
totalmente il problema è quella di aggiungere un annotation e
configurare un task ant. Francamente non vedo altri 10 problemi
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.
hybris
2011-04-01 10:25:34 UTC
Permalink
Post by Davide
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?
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."
Davide
2011-04-04 08:46:55 UTC
Permalink
Post by hybris
Post by Davide
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?
class Group {
 private Set<Product> products;
}
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."
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...
cicap
2011-04-04 19:03:11 UTC
Permalink
Post by 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.
cicap
2011-04-01 19:31:56 UTC
Permalink
Post by Davide
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?
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)
Davide
2011-04-01 09:33:33 UTC
Permalink
Post by Franco Lombardo
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".....
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.
yossarian
2011-04-01 09:37:49 UTC
Permalink
Post by Davide
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...
Se la scrivi tu la query, poi puoi ottimizzarla o meglio, la fai
ottimizzare a chi per mestiere fa solo quello.
Ci vorrebbe il pulsante "Mi piace" anche su Usenet :)
Davide
2011-04-01 10:00:46 UTC
Permalink
Post by yossarian
Post by Davide
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...
Se la scrivi tu la query, poi puoi ottimizzarla o meglio, la fai
ottimizzare a chi per mestiere fa solo quello.
Ci vorrebbe il pulsante "Mi piace" anche su Usenet :)
:)
Franco Lombardo
2011-04-01 11:06:09 UTC
Permalink
Post by Davide
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!!!!

:-)

Ciao

Franco
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.francolombardo.net
Scala, Java, As400.....
http://twitter.com/f_lombardo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cicap
2011-04-01 19:41:35 UTC
Permalink
Post by Davide
In particolare una delle cose che proprio non digerisco di hibernate
e' l'enorme quantita' di ram che utilizza.
ROTFL. Immagino tu abbia fatto approfonditi stress test e utilizzato i
migliori benchmark prima di aver valutato la cosa. Sbaglio?
Post by Davide
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...
Hai ragione, quando c'è Hibernate o meglio un ORM, le applicazioni non
sono scalabili. Ovvero il 90% delle web application Java.

Tu credi di essere un genio in un mondo di cretini per caso?
Post by Davide
Non tutti i clienti sono disposti a spendere un mucchio di quattrini
mensili solo per la voce RAM in fattura.
Notoriamente costosissima. Per inciso quanto dici significa meno di
zero, in quanto queste considerazioni possono prendere forma solo
conoscendo il numero di utenti, il tipo di applicazione, eccetera eccetera.
Post by Davide
Hibernate e spring, insieme poi, sono proprio un'accoppiata vincente
in tal senso... Non c'e' verso di far che usino meno di 300Mb di
RAM, gia' allo startup.
Ma con o senza AS? Ah, comunque se anche fosse, davvero intollerabile
nel 2011!
Post by Davide
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...
E centiana di mappaggi dal result set agli oggetti, in dieci mila
maniere diverse. Oppure lasciamo stare gli oggetti e torniamo al SQL
dentro le pagine JSP. Fantastico.
Post by Davide
Se la scrivi tu la query, poi puoi ottimizzarla o meglio, la fai
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.
--
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)
Davide
2011-04-04 08:51:00 UTC
Permalink
Post by cicap
Tu credi di essere un genio in un mondo di cretini per caso?
Un post con questi toni, a mio avviso, non merita risposta.
Lucio Benfante
2011-04-02 09:36:00 UTC
Permalink
Il 01/04/2011 11:33, Davide ha scritto:
[cut]
Post by Davide
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.
Non so che prove tu abbia fatto, ma certamente non sono Hibernate e
Spring i principali responsabili...a meno che non li stiate usando
veramente male.

Non è certo un test esaustivo, ma per curiosità ho lanciato il profiler
di NetBeans su un semplice esempio (isolato, applicazione a console,
niente application server), che non fa quasi nulla, ma usa sia Hibernate
che Spring, popolando un DB con 3-4 record e facendo un paio di
interrogazioni. Il massimo di heap che ha usato è stato attorno ai 15
MB. (e usa pure un in-memory DB)

Se a qualcuno interessa riprovare, l'esempio è quello indicato in questa
pagina:

http://www.lambico.org
Post by Davide
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...
Da queste affermazioni, sembrerebbe che sia un bel po' che non programmi
in maniera intensiva. La differenza fra avere già oggetti, o doversi
estrarre/inserire i dati tramite una libreria di basso livello come
JDBC, si traduce tipicamente in differenze di tempi di sviluppo con
rapporti 1:10, senza considerare la noia per gli sviluppatori, gli
inevitabili bug che introducono e la difficoltà di manutenere un simile
codice.
Post by Davide
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.
Quindi secondo te chi ha scritto le query che vengono generate da
Hibernate non è sufficientemente esperto?

Ovvio che si applicano a casi generali, ma mediamente sono sicuramente
migliori di quelle che è in grado di produrre uno sviluppatore medio
(non parliamo poi di quelli mediocri).

Per i casi particolari, quelli che richiedono una reale ottimizzazione,
c'è comunque modo di intervenire, sia scrivendo direttamente la query,
sia dando indicazioni a Hibernate su come una query debba essere generata.

...senza contare che in casi veramente particolari si può pure usare
direttamente JDBC, anche usando Hibernate per il resto dell'applicazione.
Post by Davide
Con hibernate puoi scrivere le query native, ma non è lo stesso, devi
comunque intervenire nel codice, perche' sono comunque due metodi
differenti.
In che senso?
Post by Davide
Dal mio punto di vista hibernate e' un pezzo in piu' che si puo'
rompere nella tua applicazione.
No, Hibernate è un singolo pezzo in più (piuttosto solido), che ti evita
di avere centinaia di pezzi in più (generalmente poco solidi) scritti
dai tuoi sviluppatori.
Post by Davide
Spring lo stesso cinema, fa cose anche interessanti, vero, ma sono
piu' i problemi che introduce che quelli che risolve...
Stesso discorso di cui sopra per Hibernate. Per inciso, Spring (come
altri framework di DI) non fa cose solamente "anche interessanti", fa
cose fondamentali per poter scrivere un applicazione ben strutturata.
Post by Davide
Ma dai, non vi e' mai capitato di dover debuggare pezzi di codice
spring o hibernate, per verificare quello che si rompe??
Di Hibernate raramente, di Spring molte volte, ma solo qunado ne faccio
un uso un po' estremo. Nell'uso normale non mi pare di aver mai
incontrato problemi che non potessero essere risolti leggendo la
documentazione o facendo una ricerca con Google. E tipicamente non erano
problemi di Spring o Hibernate, ma dell'applicazione che li utilizzava.

L'impressione che mi dai è che dici che Spring e Hibernate introducono
problemi semplicemente perchè non li conosci abbastanza.
Post by Davide
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...
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
Davide
2011-04-04 10:19:21 UTC
Permalink
Post by Lucio Benfante
Post by Davide
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.
Non so che prove tu abbia fatto, ma certamente non sono Hibernate e
Spring i principali responsabili...a meno che non li stiate usando
veramente male.
Non certo un test esaustivo, ma per curiosit ho lanciato il profiler
di NetBeans su un semplice esempio (isolato, applicazione a console,
niente application server), che non fa quasi nulla, ma usa sia Hibernate
che Spring, popolando un DB con 3-4 record e facendo un paio di
interrogazioni. Il massimo di heap che ha usato stato attorno ai 15
MB. (e usa pure un in-memory DB)
Se a qualcuno interessa riprovare, l'esempio quello indicato in questa
http://www.lambico.org
Ciao Lucio! Non verifico quanto mi dici, ma mi fido. Purtroppo il DB
che utilizzi, non penso che sia significativo. Hibernate, come ben
sai, mantiene le relazioni e i mapping tra le entita'. Con due entita'
e tre record, questa cosa non da risultati significativi.

Quello che posso dirti pero' e' che ho due applicazioni, deployate su
tomcat. Due interfacce sulla stessa base dati.

La prima, l'interfaccia di amministrazione, usa JPA con Hibernate,
spring e jersey (JAX-RS).

Faccio partire il Tomcat con eclipse e ottengo un dato: 198M.

Seconda Applicazione, il sito internet: Usa JDBC con una libreria di
pochi KB, che si occupa di gestire le connessioni e serializzare i
dati e struts 2.

Faccio partire il Tomcat con eclipse e ottengo un altro dato: 116M

Se comincio ad utilizzare la prima applicazione, mi accorgo che la
memoria occupata sale a circa 350M, poi si ferma correttamente.
Se comincio ad utilizzare la seconda, sale, ma non supera i 200M.

La cosa interessante e' che, mentre la prima e' un'interfaccia di
amministrazione ed ha una decina di utenti contemporanei, la seconda
ha raggiunto le 60 richieste al secondo.

Entrambe funzionano bene sotto carico, ma la prima ha bisogno di piu'
memoria.

Nemmeno questo dato e' significativo. potrebbero esserci mille altre
cose in mezzo, ma tutte le volte che uso hibernate, mi occorre piu'
memoria. E' 5 anni che noto questa cosa e non sai quante menate che mi
faceva il sistemista ed io gli dicevo piu' o meno quello che mi dici
tu... La memoria non e' un problema, usiamo macchine piu' potenti....

Ora mi rendo conto che uno che deve gestire un centinaio di
applicazioni, la memoria e' un problema al quale prestare particolare
attenzione.

Hibernate, per com'e' stato pensato e per il solo fatto che usa vari
livelli di cache non puo' usare poca memoria e non c'e' nulla per cui
arrabbiarsi in questo.
Post by Lucio Benfante
Post by Davide
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...
Da queste affermazioni, sembrerebbe che sia un bel po' che non programmi
in maniera intensiva. La differenza fra avere gi oggetti, o doversi
estrarre/inserire i dati tramite una libreria di basso livello come
JDBC, si traduce tipicamente in differenze di tempi di sviluppo con
rapporti 1:10, senza considerare la noia per gli sviluppatori, gli
inevitabili bug che introducono e la difficolt di manutenere un simile
codice.
Caro mio, come ti sbagli... Sviluppo eccome e, se mi lamento di
hibernate, e' proprio perche' non riesco ad esser veloce come vorrei!

Ripeto, scrivere le query in SQL, e' un grande vantaggio! Prima di
tutto fai copia e incolla in toad, mysql manager o quello che usi per
eseguire le query, la lanci e vedi subito dov'e' il problema, se
funziona, come funziona, i dati restituiti...

Per quanto riguarda il rapporto 1:10, beh, mi spiace, ma non sono
nuovamente d'accordo. Anche con hibernate introduci i bug, come con
JDBC. Solo che quando capita, io almeno, faccio piu' fatica a capire
dove si trovi il problema, per via della pila di cose che ci sono tra
il tuo codice e la base dati.

Purtroppo ho la percezione che quando dici "un simile codice", intendi
qualcosa come le JSP, con dentro schiantate le query.

Si puo' essere molto ordinati, anche senza usare hibernate, sai??? Io
ad esempio carico le query da file .sql, inseriti nei package,
affianco alla classe che li usa!

Non so, UserService.java, usa un file che si chiama SelectUser.sql,
posto nello stesso file.

E' dal 2005 che non scrivo una riga SQL dentro le classi.

Come dicevo prima, ci sono mille possibilita' tra JPA e JDBC.
Post by Lucio Benfante
Post by Davide
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.
Quindi secondo te chi ha scritto le query che vengono generate da
Hibernate non sufficientemente esperto?
Chi scrive le query hibernate, sara' sicuramente il piu' esperto del
mondo, non ho dubbi... capisci pero' che ci sono tutta una serie di
possibilita' che trovo difficile che un generatore di query, generico,
sia performante con tutti i database server esistenti e in tutti i
casi possibili...

Tutto qui! In linea di massima, hibernate traduce l'HQL in query
performanti, non ho dubbi in merito.
Post by Lucio Benfante
Ovvio che si applicano a casi generali, ma mediamente sono sicuramente
migliori di quelle che in grado di produrre uno sviluppatore medio
(non parliamo poi di quelli mediocri).
Forse hai ragione, ma penso sia piu' opportuno investire su meno
persone di qualita' che su molte incapaci..
Poi la maggior parte delle query sono anche facili da scrivere, non
sono tutte super-join complesse!
Post by Lucio Benfante
Per i casi particolari, quelli che richiedono una reale ottimizzazione,
c' comunque modo di intervenire, sia scrivendo direttamente la query,
sia dando indicazioni a Hibernate su come una query debba essere generata.
...senza contare che in casi veramente particolari si pu pure usare
direttamente JDBC, anche usando Hibernate per il resto dell'applicazione.
Post by Davide
Con hibernate puoi scrivere le query native, ma non lo stesso, devi
comunque intervenire nel codice, perche' sono comunque due metodi
differenti.
In che senso?
...senza contare che in casi veramente particolari si pu pure usare
direttamente JDBC, anche usando Hibernate per il resto dell'applicazione.
Post by Davide
Dal mio punto di vista hibernate e' un pezzo in piu' che si puo'
rompere nella tua applicazione.
No, Hibernate un singolo pezzo in pi (piuttosto solido), che ti evita
di avere centinaia di pezzi in pi (generalmente poco solidi) scritti
dai tuoi sviluppatori.
Perche' centinaia? Penso che abbiamo in mente modelli di sviluppo
molto differenti, perche' personalmente uso una libreria testata,
collaudata, solida, sempre quella da anni...

Ormai sono 2 anni che non trovo un baco...
Hibernate non e' una scatola chiusa, anch'esso e' fatto di componenti,
sicuramente solidi, ma che funzionano con la loro logica, il
programmatore (io ad esempio) puo' comunque introdurre errori, come
con altre librerie.
Post by Lucio Benfante
Post by Davide
Spring lo stesso cinema, fa cose anche interessanti, vero, ma sono
piu' i problemi che introduce che quelli che risolve...
Stesso discorso di cui sopra per Hibernate. Per inciso, Spring (come
altri framework di DI) non fa cose solamente "anche interessanti", fa
cose fondamentali per poter scrivere un applicazione ben strutturata.
All'XP, nell'incontro cui faceva rif. Francesco, si parlava proprio di
come si possa eliminare l'uso di spring e della sua "essenzialita'",
in modo molto semplice.
Post by Lucio Benfante
Post by Davide
Ma dai, non vi e' mai capitato di dover debuggare pezzi di codice
spring o hibernate, per verificare quello che si rompe??
Di Hibernate raramente, di Spring molte volte, ma solo qunado ne faccio
un uso un po' estremo. Nell'uso normale non mi pare di aver mai
incontrato problemi che non potessero essere risolti leggendo la
documentazione o facendo una ricerca con Google. E tipicamente non erano
problemi di Spring o Hibernate, ma dell'applicazione che li utilizzava.
L'impressione che mi dai che dici che Spring e Hibernate introducono
problemi semplicemente perch non li conosci abbastanza.
Probabile che tu abbia ragione. Ma forse hanno una curva di
apprendimento cosi' ripida, che il mio tempo libero preferisco
spenderlo ad arrampicarmi su altre vette, piuttosto che
sull'inarrivabile conoscenza di hibernate e spring.
Post by Lucio Benfante
Post by Davide
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...
Io mi scosto spesso (e volentieri :) ) da quello che tipicamente
l'utilizzo tipico si Spring e Hibernate (guarda ad esempio come funziona
il mio Lambicowww.lambico.org), ma non mi pare che non funzioni "pi un
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.
cicap
2011-04-04 19:15:28 UTC
Permalink
Post by Davide
Faccio partire il Tomcat con eclipse e ottengo un dato: 198M.
Seconda Applicazione, il sito internet: Usa JDBC con una libreria di
pochi KB, che si occupa di gestire le connessioni e serializzare i
dati e struts 2.
Faccio partire il Tomcat con eclipse e ottengo un altro dato: 116M
E' possibile che una parte sia dovuta alle numerose librerie di terze
parti da cui Hibernate dipende, che occupano svariati mega in tutto.
Un possibile modo per risparmiare spazio è quello di installarle a
livello di Application Server piuttosto che a livello di singola
applicazione.
Post by Davide
capisci pero' che ci sono tutta una serie di
possibilita' che trovo difficile che un generatore di query, generico,
sia performante con tutti i database server esistenti e in tutti i
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...
Lucio Benfante
2011-04-05 12:11:53 UTC
Permalink
Post by Davide
Ciao Lucio! Non verifico quanto mi dici, ma mi fido. Purtroppo il DB
che utilizzi, non penso che sia significativo. Hibernate, come ben
sai, mantiene le relazioni e i mapping tra le entita'. Con due entita'
e tre record, questa cosa non da risultati significativi.
Non capisco. Secondo te l'occupazione di memoria è causata dai dati di
mapping?

[cut]
Post by Davide
Entrambe funzionano bene sotto carico, ma la prima ha bisogno di piu'
memoria.
Sarebbe interessante fare un confronto dei costi di sviluppo delle due
applicazione, e dei costi di manutenzione, soprattutto in casi in cui si
dovesse gestire la necessità di scalare maggiormente. Ad esempio, quanto
sarebbe facile introdurre una cache di secondo livello nel primo caso, e
quanto nel secondo? Ne sarebbe valsa la pena solo per risparmiare un po'
di memoria? (virtuale...sì, perché sarei quasi certo che la memoria che
riporti è quella totale allocata, non quella in uso).
Post by Davide
Nemmeno questo dato e' significativo. potrebbero esserci mille altre
cose in mezzo, ma tutte le volte che uso hibernate, mi occorre piu'
memoria. E' 5 anni che noto questa cosa e non sai quante menate che mi
faceva il sistemista ed io gli dicevo piu' o meno quello che mi dici
tu... La memoria non e' un problema, usiamo macchine piu' potenti....
Non è una questione di potenza, è una semplice questione di costi. Ma
non si possono trascurare i costi di sviluppo e manutenzione, che
normalmente sono preponderanti rispetto ai costi dell'hardware.
Post by Davide
Ora mi rendo conto che uno che deve gestire un centinaio di
applicazioni, la memoria e' un problema al quale prestare particolare
attenzione.
Hibernate, per com'e' stato pensato e per il solo fatto che usa vari
livelli di cache non puo' usare poca memoria e non c'e' nulla per cui
arrabbiarsi in questo.
Se la memoria è realmente un problema, allora forse sarebbe il caso di
studiarlo un po' il problema, non trovi? Se ti limiti a lanciare il
server (con Eclipse) e guardare quanto è il max heap, non credo sia
sufficiente per un'analisi.

Sempre per curiosità, senza nessuna pretesa che abbia troppo significato
generale, questa volta ho lanciato il profiler su una webapp, che non è
un semplice esempio, ma un'applicazione reale, decisamente pesante e
complessa, che usa un DB di parecchi GB e parecchie entità, e fa pure
image processing. Inoltre è la versione 2 di un'applicazione molto
vecchia, completamente riscritta, che precedentemente faceva uso di solo
JDBC. Quindi il DB è un DB legacy, con una struttura non
specificatamente pensata per Hibernate.

Senza fare particolari ottimizzazioni della VM (e ovviamente senza fare
nessun test di carico, ma semplicemente facendo partire l'applicazione e
usandone alcune funzionalità), fino a dopo lo startup il max heap size
si è mantenuto al di sotto dei 50MB, e lo used heap size attorno ai
30MB. Anche successivamente, usando le funzionalità normali
dell'applicazione (quelle che fanno semplice CRUD, per intenderci), i
valori sono rimasti sostanzialmente quelli. Solo usando le funzionalità
più "intense" dell'applicazione l'uso della memoria è salito, ma
forzando il GC è tornata ben al di sotto dei 50MB, quindi non era
memoria realmente non disponibile.

Ripeto nessuna pretesa che questa semplice prova possa avere particolare
significato, ma non mi sembrano valori particolarmente critici per una
webapp, tali da attribuire a Spring ed Hibernate gli svantaggi che tu dici.
Post by Davide
Caro mio, come ti sbagli... Sviluppo eccome e, se mi lamento di
hibernate, e' proprio perche' non riesco ad esser veloce come vorrei!
E con il solo JDBC ci riesci? Permettimi di dubitarne.
Post by Davide
Ripeto, scrivere le query in SQL, e' un grande vantaggio! Prima di
tutto fai copia e incolla in toad, mysql manager o quello che usi per
eseguire le query, la lanci e vedi subito dov'e' il problema, se
funziona, come funziona, i dati restituiti...
La stessa cosa la puoi fare con le query HQL: strumenti come SQuirreL
SQl (ma non solo) sono perfettamente in grado di farti eseguire le query
HQL che vuoi (con autocompletamento e tutto).

...ma visto che frequenti un XP group, forse la via migliore sarebbe
quella di scrivere dei test, invece che provare delle query a mano.
Post by Davide
Per quanto riguarda il rapporto 1:10, beh, mi spiace, ma non sono
nuovamente d'accordo. Anche con hibernate introduci i bug, come con
JDBC. Solo che quando capita, io almeno, faccio piu' fatica a capire
dove si trovi il problema, per via della pila di cose che ci sono tra
il tuo codice e la base dati.
Francamente a me questo non succede. Anzi, tipicamente faccio molta più
fatica a capire codice che userà pure "solo" JDBC, ma a cui è stato
strutturato sopra praticamente un mini-framework, fatto in casa,
tipicamente scarsamente documentato...e che capisce al volo solo chi lo
ha scritto.

Quanto alla produttività...non è una questione di opinioni. Provo a
dimostrartelo.

1..2..3...via:

@Entity
public class Person implements Serializable {
@Id
private Long id;
private String nome;
private String cognome;
private int eta;

...(in NB) Alt+Ins...Generate getters and setters...
}

...stop...totale circa 40 secondi. E con quella semplice classe ci
estraggo i dati dal DB, ce li inserisco, li modifico...se voglio creo
pure automaticamente lo schema del database, ecc. ecc...

Non devo prendermi i singoli campi della tabella e scrivere il codice
per metterli dentro ad oggetti.

Quanto codice avresti dovuto scrivere per esprimere la stessa cosa? E
quanto tempo ci avresti messo?

Ovvio che esistono casi più complessi e che richiedono conoscenze
maggiori, ma in termini di produttività non c'è paragone al dover
utilizzare solamente JDBC. Se poi avete il vostro framework al di sopra
di JDBC, che vi permette di essere altrettanto produttivi...che ne dite
di farcelo conoscere?
Post by Davide
Purtroppo ho la percezione che quando dici "un simile codice", intendi
qualcosa come le JSP, con dentro schiantate le query.
No intendo quello di cui parlavo sopra (mini-framework).
Post by Davide
Si puo' essere molto ordinati, anche senza usare hibernate, sai??? Io
ad esempio carico le query da file .sql, inseriti nei package,
affianco alla classe che li usa!
Non so, UserService.java, usa un file che si chiama SelectUser.sql,
posto nello stesso file.
E' dal 2005 che non scrivo una riga SQL dentro le classi.
Come dicevo prima, ci sono mille possibilita' tra JPA e JDBC.
Certo...mille possibilità, che capisce solo chi le ha scritte. Il
vantaggio nell'utilizzo di un framework noto e diffuso è appunto che
tipicamente la documentazione esiste, e le soluzioni ai problemi si trovano.
Post by Davide
Chi scrive le query hibernate, sara' sicuramente il piu' esperto del
mondo, non ho dubbi... capisci pero' che ci sono tutta una serie di
possibilita' che trovo difficile che un generatore di query, generico,
sia performante con tutti i database server esistenti e in tutti i
casi possibili...
I casi non sono poi molti...il modello relazionale è un modello
piuttosto semplice.

Inoltre le query vengono generate ad-hoc per ciascun database server.
Post by Davide
Tutto qui! In linea di massima, hibernate traduce l'HQL in query
performanti, non ho dubbi in merito.
Bene, quindi perchè non usarlo, sfruttando le capacità degli esperti
solo per le query realmente critiche?
Post by Davide
Post by Lucio Benfante
Ovvio che si applicano a casi generali, ma mediamente sono sicuramente
migliori di quelle che in grado di produrre uno sviluppatore medio
(non parliamo poi di quelli mediocri).
Forse hai ragione, ma penso sia piu' opportuno investire su meno
persone di qualita' che su molte incapaci..
Poi la maggior parte delle query sono anche facili da scrivere, non
sono tutte super-join complesse!
Il che significa semplicemente che in Hibernate non sono solo facili, ma
addirittura banali.
Post by Davide
Perche' centinaia? Penso che abbiamo in mente modelli di sviluppo
molto differenti, perche' personalmente uso una libreria testata,
collaudata, solida, sempre quella da anni...
...che però è conosciuta solo nel tuo gruppo di lavoro.
Post by Davide
Ormai sono 2 anni che non trovo un baco...
Hibernate non e' una scatola chiusa, anch'esso e' fatto di componenti,
sicuramente solidi, ma che funzionano con la loro logica, il
programmatore (io ad esempio) puo' comunque introdurre errori, come
con altre librerie.
Ovvio...la differenza rispetto alla vostra libreria è che Hibernate è
ampiamente documentato ed esistono migliaia di esperti, al di fuori del
vostro gruppo di lavoro, a cui chiedere in caso di problemi.
Post by Davide
All'XP, nell'incontro cui faceva rif. Francesco, si parlava proprio di
come si possa eliminare l'uso di spring e della sua "essenzialita'",
in modo molto semplice.
Che si possa non ho dubbi...ma la domanda è "perchè"? Butti via un
componente diffuso e documentato, per sostituirlo con qualcosa di "fatto
in casa"?
Post by Davide
Post by Lucio Benfante
L'impressione che mi dai che dici che Spring e Hibernate introducono
problemi semplicemente perch non li conosci abbastanza.
Probabile che tu abbia ragione. Ma forse hanno una curva di
apprendimento cosi' ripida, che il mio tempo libero preferisco
spenderlo ad arrampicarmi su altre vette, piuttosto che
sull'inarrivabile conoscenza di hibernate e spring.
Boh...io ho visto studenti delle superiori in stage che dopo due giorni
(ovviamente opportunamente guidati) erano in grado di scrivere codice
usando Spring e Hibernate. Non mi pare una curva tanto ripida. Certo,
qualcuno di esperto ci vuole nel gruppo...è quello che dicevi tu sopra:
bisogna investire nelle competenze. Se hai tutti incapaci...anche JDBC
da solo ha le sue belle magagne da capire.
Post by Davide
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...
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
Davide
2011-04-06 19:42:29 UTC
Permalink
Post by Lucio Benfante
Post by Davide
Ciao Lucio! Non verifico quanto mi dici, ma mi fido. Purtroppo il DB
che utilizzi, non penso che sia significativo. Hibernate, come ben
sai, mantiene le relazioni e i mapping tra le entita'. Con due entita'
e tre record, questa cosa non da risultati significativi.
Non capisco. Secondo te l'occupazione di memoria è causata dai dati di
mapping?
Piu' oggetti hai in memoria, piu' memoria utilizzi. Gli ORM hanno
inoltre tante feature carine, come cache di primo e secondo livello,
che occupano memoria.
Post by Lucio Benfante
Post by Davide
Entrambe funzionano bene sotto carico, ma la prima ha bisogno di piu'
memoria.
Sarebbe interessante fare un confronto dei costi di sviluppo delle due
applicazione, e dei costi di manutenzione, soprattutto in casi in cui si
dovesse gestire la necessità di scalare maggiormente. Ad esempio, quanto
sarebbe facile introdurre una cache di secondo livello nel primo caso, e
quanto nel secondo? Ne sarebbe valsa la pena solo per risparmiare un po'
di memoria? (virtuale...sì, perché sarei quasi certo che la memoria che
riporti è quella totale allocata, non quella in uso).
Non ha alcun valore fare il paragone, perche' si occupano di ambiti
differenti della stessa applicazione, la prima e' l'interfaccia
utente, l'altra la navigazione dei report.

L'intero progetto 10 mesi/uomo, di cui solo uno per la parte di
produzione report (Quella non-hibernate)

Ma non vale, perche' fanno cose, come dicevo, differenti.
Post by Lucio Benfante
Post by Davide
Nemmeno questo dato e' significativo. potrebbero esserci mille altre
cose in mezzo, ma tutte le volte che uso hibernate, mi occorre piu'
memoria. E' 5 anni che noto questa cosa e non sai quante menate che mi
faceva il sistemista ed io gli dicevo piu' o meno quello che mi dici
tu... La memoria non e' un problema, usiamo macchine piu' potenti....
Non è una questione di potenza, è una semplice questione di costi. Ma
non si possono trascurare i costi di sviluppo e manutenzione, che
normalmente sono preponderanti rispetto ai costi dell'hardware.
Se il lavoro lo fai per bene, i costi di manutenzione sono
equiparabili. Quelli di sviluppo non so. Perche' se da un lato mi sono
scritto le query, dall'altro lato, ho avuto momenti in cui sono
diventato pazzo a mettere insieme i pezzi, quindi con perdita di
tempi.
Post by Lucio Benfante
Post by Davide
Ora mi rendo conto che uno che deve gestire un centinaio di
applicazioni, la memoria e' un problema al quale prestare particolare
attenzione.
Hibernate, per com'e' stato pensato e per il solo fatto che usa vari
livelli di cache non puo' usare poca memoria e non c'e' nulla per cui
arrabbiarsi in questo.
Se la memoria è realmente un problema, allora forse sarebbe il caso di
studiarlo un po' il problema, non trovi? Se ti limiti a lanciare il
server (con Eclipse) e guardare quanto è il max heap, non credo sia
sufficiente per un'analisi.
La memoria non e' un problema finche' la differenza non e' di 100Mb
per applicazione e, soprattutto, finche' il cliente ha un posto dove
mettere l'applicazione. Se, come spesso succede, il cliente opta per
un hosting oppure ha numerose applicazioni installate, credimi che
scegliere una soluzione con un giga o mezzo giga di ram, credimi che
ha un costo che al cliente interessa, eccome...
Post by Lucio Benfante
Sempre per curiosità, senza nessuna pretesa che abbia troppo significato
generale, questa volta ho lanciato il profiler su una webapp, che non è
un semplice esempio, ma un'applicazione reale, decisamente pesante e
complessa, che usa un DB di parecchi GB e parecchie entità, e fa pure
image processing. Inoltre è la versione 2 di un'applicazione molto
vecchia, completamente riscritta, che precedentemente faceva uso di solo
JDBC. Quindi il DB è un DB legacy, con una struttura non
specificatamente pensata per Hibernate.
Senza fare particolari ottimizzazioni della VM (e ovviamente senza fare
nessun test di carico, ma semplicemente facendo partire l'applicazione e
usandone alcune funzionalità), fino a dopo lo startup il max heap size
si è mantenuto al di sotto dei 50MB, e lo used heap size attorno ai
30MB. Anche successivamente, usando le funzionalità normali
dell'applicazione (quelle che fanno semplice CRUD, per intenderci), i
valori sono rimasti sostanzialmente quelli. Solo usando le funzionalità
più "intense" dell'applicazione l'uso della memoria è salito, ma
forzando il GC è tornata ben al di sotto dei 50MB, quindi non era
memoria realmente non disponibile.
Ripeto nessuna pretesa che questa semplice prova possa avere particolare
significato, ma non mi sembrano valori particolarmente critici per una
webapp, tali da attribuire a Spring ed Hibernate gli svantaggi che tu dici.
Perdonami se insisto, ma non e' un dato significativo nemmeno
questo... Le decine di librerie usate non sono contemplate nel
conteggio.
Post by Lucio Benfante
Post by Davide
Caro mio, come ti sbagli... Sviluppo eccome e, se mi lamento di
hibernate, e' proprio perche' non riesco ad esser veloce come vorrei!
E con il solo JDBC ci riesci? Permettimi di dubitarne.
Dubita pure
Post by Lucio Benfante
Post by Davide
Ripeto, scrivere le query in SQL, e' un grande vantaggio! Prima di
tutto fai copia e incolla in toad, mysql manager o quello che usi per
eseguire le query, la lanci e vedi subito dov'e' il problema, se
funziona, come funziona, i dati restituiti...
La stessa cosa la puoi fare con le query HQL: strumenti come SQuirreL
SQl (ma non solo) sono perfettamente in grado di farti eseguire le query
HQL che vuoi (con autocompletamento e tutto).
Squirrel, vero, un'altro strumento davvero performante...
Post by Lucio Benfante
...ma visto che frequenti un XP group, forse la via migliore sarebbe
quella di scrivere dei test, invece che provare delle query a mano.
Che scemo, perche' non c'ho pensato prima? Perche' non ho scritto un
test ogni volta che devo provare una query??? Ah si, ora ricordo, un
conto e' testare un applicazione, a testare jdbc ci pensera' chi ha
fatto jdbc...
Post by Lucio Benfante
Post by Davide
Per quanto riguarda il rapporto 1:10, beh, mi spiace, ma non sono
nuovamente d'accordo. Anche con hibernate introduci i bug, come con
JDBC. Solo che quando capita, io almeno, faccio piu' fatica a capire
dove si trovi il problema, per via della pila di cose che ci sono tra
il tuo codice e la base dati.
Francamente a me questo non succede. Anzi, tipicamente faccio molta più
fatica a capire codice che userà pure "solo" JDBC, ma a cui è stato
strutturato sopra praticamente un mini-framework, fatto in casa,
tipicamente scarsamente documentato...e che capisce al volo solo chi lo
ha scritto.
Quanto alla produttività...non è una questione di opinioni. Provo a
dimostrartelo.
@Entity
public class Person implements Serializable {
   private Long id;
   private String nome;
   private String cognome;
   private int eta;
...(in NB) Alt+Ins...Generate getters and setters...
}
...stop...totale circa 40 secondi. E con quella semplice classe ci
estraggo i dati dal DB, ce li inserisco, li modifico...se voglio creo
pure automaticamente lo schema del database, ecc. ecc...
Stop mica tanto... I dati li estrai anche con hibernate... quello che
mi hai postato e' un'entity.
Post by Lucio Benfante
Non devo prendermi i singoli campi della tabella e scrivere il codice
per metterli dentro ad oggetti.
Quanto codice avresti dovuto scrivere per esprimere la stessa cosa? E
quanto tempo ci avresti messo?
File SelectPerson.sql:
SELECT ID,
NOME,
COGNOME,
ETA
FROM PERSON
WHERE (:ID IS NULL OR ID = :ID)
ORDER BY ID

Classe PersonService:
[...]
public Map<String, Object> getPerson(Long id){
DataLink dl = new DataLink();
try{
Map<String, Object> params = new HashMap<String, Object>();
params.put("ID", id);
return dl.execQuery(
DataModule.getQuery(
PersonService.class,
"SelectPerson",
params
)
).getFirst();
} finally {
dl.close();
}
}
[...]

getFirst() restituisce il primo elemento oppure un elemento vuoto. Il
risultato della query e':

List<Map<String, Object>>

E' vero che scrivi piu' codice, ma tu hai barato... Hai scritto solo
il POJO...
Post by Lucio Benfante
Ovvio che esistono casi più complessi e che richiedono conoscenze
maggiori, ma in termini di produttività non c'è paragone al dover
utilizzare solamente JDBC. Se poi avete il vostro framework al di sopra
di JDBC, che vi permette di essere altrettanto produttivi...che ne dite
di farcelo conoscere?
Certo, si chiama SQLRepository, e' stata scritta nel 2005 ed e'
opensource su google code, anche se ha necessita' di una bella
aggiornata.

Su una cosa hai ragione, non c'è documentazione a riguardo e questo e'
sicuramente un problema.
Post by Lucio Benfante
Post by Davide
Purtroppo ho la percezione che quando dici "un simile codice", intendi
qualcosa come le JSP, con dentro schiantate le query.
No intendo quello di cui parlavo sopra (mini-framework).
Post by Davide
Si puo' essere molto ordinati, anche senza usare hibernate, sai??? Io
ad esempio carico le query da file .sql, inseriti nei package,
affianco alla classe che li usa!
Non so, UserService.java, usa un file che si chiama SelectUser.sql,
posto nello stesso file.
E' dal 2005 che non scrivo una riga SQL dentro le classi.
Come dicevo prima, ci sono mille possibilita' tra JPA e JDBC.
Certo...mille possibilità, che capisce solo chi le ha scritte. Il
vantaggio nell'utilizzo di un framework noto e diffuso è appunto che
tipicamente la documentazione esiste, e le soluzioni ai problemi si trovano.
Questo non puoi dirlo finche' non vedi il codice... Oggi, per via
della dependency injection, e' molto piu' facile scrivere codice
incomprensibile... Per non parlare dei proxy...

Ho visto robe scritte con java 5 che, solo per voler usare una
funzionalita' specifica del codice, per cercare di capire quel che
fanno, ti viene una crisi epilettica...
Post by Lucio Benfante
Post by Davide
Chi scrive le query hibernate, sara' sicuramente il piu' esperto del
mondo, non ho dubbi... capisci pero' che ci sono tutta una serie di
possibilita' che trovo difficile che un generatore di query, generico,
sia performante con tutti i database server esistenti e in tutti i
casi possibili...
I casi non sono poi molti...il modello relazionale è un modello
piuttosto semplice.
Inoltre le query vengono generate ad-hoc per ciascun database server.
Post by Davide
Tutto qui! In linea di massima, hibernate traduce l'HQL in query
performanti, non ho dubbi in merito.
Bene, quindi perchè non usarlo, sfruttando le capacità degli esperti
solo per le query realmente critiche?
Ascolta, va bene tutto, ma ora mi devi dire dove sono performanti le
criteria query.
Post by Lucio Benfante
Post by Davide
Post by Lucio Benfante
Ovvio che si applicano a casi generali, ma mediamente sono sicuramente
migliori di quelle che in grado di produrre uno sviluppatore medio
(non parliamo poi di quelli mediocri).
Forse hai ragione, ma penso sia piu' opportuno investire su meno
persone di qualita' che su molte incapaci..
Poi la maggior parte delle query sono anche facili da scrivere, non
sono tutte super-join complesse!
Il che significa semplicemente che in Hibernate non sono solo facili, ma
addirittura banali.
Post by Davide
Perche' centinaia? Penso che abbiamo in mente modelli di sviluppo
molto differenti, perche' personalmente uso una libreria testata,
collaudata, solida, sempre quella da anni...
...che però è conosciuta solo nel tuo gruppo di lavoro.
Sembra che voglio sponsorizzare le mie librerie, che Dio ce ne
scampi!
Non sono così bravo... Il concetto e' un'altro, spesso usare una roba
troppo articolata, solo perche' la usano tutti e' sbagliato...

Alle volte una roba che conosci da anni, di cui sai bene pregi e
difetti, e' meglio.
Post by Lucio Benfante
Post by Davide
Ormai sono 2 anni che non trovo un baco...
Hibernate non e' una scatola chiusa, anch'esso e' fatto di componenti,
sicuramente solidi, ma che funzionano con la loro logica, il
programmatore (io ad esempio) puo' comunque introdurre errori, come
con altre librerie.
Ovvio...la differenza rispetto alla vostra libreria è che Hibernate è
ampiamente documentato ed esistono migliaia di esperti, al di fuori del
vostro gruppo di lavoro, a cui chiedere in caso di problemi.
Esperti dei quali non hai bisogno, perche' non usi hibernate. E' piu'
facile che si abbia bisogno di un DBA.

Dai una classe java ad un DBA e dimmi che ti risponde...
Post by Lucio Benfante
Post by Davide
All'XP, nell'incontro cui faceva rif. Francesco, si parlava proprio di
come si possa eliminare l'uso di spring e della sua "essenzialita'",
in modo molto semplice.
Che si possa non ho dubbi...ma la domanda è "perchè"? Butti via un
componente diffuso e documentato, per sostituirlo con qualcosa di "fatto
in casa"?
Per lo stesso motivo cui e' nato tutto... Introdurre un componente in
piu' che si puo' rompere, introduce complessita' nell'architettura.
Spesso piu' le cose sono semplici, meglio e'.
Post by Lucio Benfante
Post by Davide
Post by Lucio Benfante
L'impressione che mi dai che dici che Spring e Hibernate introducono
problemi semplicemente perch non li conosci abbastanza.
Probabile che tu abbia ragione. Ma forse hanno una curva di
apprendimento cosi' ripida, che il mio tempo libero preferisco
spenderlo ad arrampicarmi su altre vette, piuttosto che
sull'inarrivabile conoscenza di hibernate e spring.
Boh...io ho visto studenti delle superiori in stage che dopo due giorni
(ovviamente opportunamente guidati) erano in grado di scrivere codice
usando Spring e Hibernate. Non mi pare una curva tanto ripida. Certo,
bisogna investire nelle competenze. Se hai tutti incapaci...anche JDBC
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.
cicap
2011-04-06 20:18:42 UTC
Permalink
Post by Davide
Piu' oggetti hai in memoria, piu' memoria utilizzi. Gli ORM hanno
inoltre tante feature carine, come cache di primo e secondo livello,
che occupano memoria.
Due megabyte su 20 mila entity. Davvero un problemone. Tu invece
continuando a gettare l'amo sul database, si che risparmi in memoria,
CPU e migliori le prestazioni.
Post by Davide
public Map<String, Object> getPerson(Long id){
DataLink dl = new DataLink();
try{
Map<String, Object> params = new HashMap<String, Object>();
params.put("ID", id);
return dl.execQuery(
DataModule.getQuery(
PersonService.class,
"SelectPerson",
params
)
).getFirst();
} finally {
dl.close();
}
}
[...]
getFirst() restituisce il primo elemento oppure un elemento vuoto. Il
List<Map<String, Object>>
Bravo, ora aggiungi anche codice per leggere la mappa e impostare il
valore del POJO.

Ah per inciso non userei una simile libreria neanche per mi pagassi per
farlo
(http://code.google.com/p/sqlrepository/source/browse/trunk/src/main/java/it/sweetlab/db/DataLink.java):
notare come chiudi i resultset (dentro il try!!!!!!!!!!!!!!!!!!!!) e
amenità varie.
Post by Davide
Certo, si chiama SQLRepository, e' stata scritta nel 2005 ed e'
opensource su google code, anche se ha necessita' di una bella
aggiornata.
Probabilmente ha bisogno di un intensivo bug fixing...altrochè Hibernate.
In sostanza chiunque lo dovesse usare dovrebbe passare centinaia di ore
a debuggare e risolvere decine di righe di codice di una libreria non
documentata e probabilmente non scritta secondo i migliori crismi della
programmazione moderna (questo senza volerti dare pagellini sulle capacità).

Anzi no, ci potresti mettere le mani solo tu. Ne sono certo. Figata,
questo si che è progresso!
Post by Davide
Questo non puoi dirlo finche' non vedi il codice... Oggi, per via
della dependency injection, e' molto piu' facile scrivere codice
incomprensibile... Per non parlare dei proxy...
AH AH AH AH AH AH. La perla finale. Almeno per me, visto che mi fermo
qui inorridito.
Lucio Benfante
2011-04-06 23:32:04 UTC
Permalink
Post by Davide
Piu' oggetti hai in memoria, piu' memoria utilizzi. Gli ORM hanno
inoltre tante feature carine, come cache di primo e secondo livello,
che occupano memoria.
Non è che ce le abbiano solo gli orm...e tu continui a parlare di
feature "carine" o "anche interessanti". Invece sono feature essenziali
per un'applicazione che abbia minimamente la possibilità di scalare.

[cut]
Post by Davide
Post by Lucio Benfante
Post by Davide
Caro mio, come ti sbagli... Sviluppo eccome e, se mi lamento di
hibernate, e' proprio perche' non riesco ad esser veloce come vorrei!
E con il solo JDBC ci riesci? Permettimi di dubitarne.
Dubita pure
No, ora che ho visto cosa usate per sviluppare, ne ho la certezza.
Post by Davide
Post by Lucio Benfante
...ma visto che frequenti un XP group, forse la via migliore sarebbe
quella di scrivere dei test, invece che provare delle query a mano.
Che scemo, perche' non c'ho pensato prima? Perche' non ho scritto un
test ogni volta che devo provare una query??? Ah si, ora ricordo, un
conto e' testare un applicazione, a testare jdbc ci pensera' chi ha
fatto jdbc...
Chi ha parlato di testare JDBC? Sono le query che scrivi che devi testare.
Post by Davide
Stop mica tanto... I dati li estrai anche con hibernate... quello che
mi hai postato e' un'entity.
Sì, ed è l'unica cosa che mi occorre per estrarre ed inserire dati nel
di DB.
Post by Davide
getFirst() restituisce il primo elemento oppure un elemento vuoto. Il
List<Map<String, Object>>
<ironic_mode>
molto comoda da usare
</ironic_mode>
Post by Davide
E' vero che scrivi piu' codice, ma tu hai barato... Hai scritto solo
il POJO...
Tu invece hai scritto il codice per l'esecuzione di una query (e ci
sarebbero molte cosa da dire su tale codice...ma mi astengo). Vorrei
solo farti notare quanto codice hai scritto solo per l'esecuzione della
query...e ancora manca tutto il codice di utilizzo dei risultati della
query (che nel tuo caso è necessariamente codice non tipizzato, e che
implica la conoscenza dei campi della query stessa).
Post by Davide
Post by Lucio Benfante
Ovvio che esistono casi più complessi e che richiedono conoscenze
maggiori, ma in termini di produttività non c'è paragone al dover
utilizzare solamente JDBC. Se poi avete il vostro framework al di sopra
di JDBC, che vi permette di essere altrettanto produttivi...che ne dite
di farcelo conoscere?
Certo, si chiama SQLRepository, e' stata scritta nel 2005 ed e'
opensource su google code, anche se ha necessita' di una bella
aggiornata.
Su una cosa hai ragione, non c'è documentazione a riguardo e questo e'
sicuramente un problema.
No il problema è che io ho un'altra idea di produttività.
Post by Davide
Ascolta, va bene tutto, ma ora mi devi dire dove sono performanti le
criteria query.
Che c'entra? I criteria sono solo un modo per costruire una query. La
query risultante è perfomante esattamente come se fosse stata scritta a
mano.
Post by Davide
Alle volte una roba che conosci da anni, di cui sai bene pregi e
difetti, e' meglio.
Sì...e nel mio caso le cose che conosco da anni e di cui so bene pregi e
difetti sono (fra le altre cose) Spring e Hibernate, ma secondo me
dovresti sforzarti di conoscerle un po' di più anche tu...altrimenti
posso capire che sembrino qualcosa di paragonabile alla magia e su cui
non si ha alcun controllo.
Post by Davide
Post by Lucio Benfante
Ovvio...la differenza rispetto alla vostra libreria è che Hibernate è
ampiamente documentato ed esistono migliaia di esperti, al di fuori del
vostro gruppo di lavoro, a cui chiedere in caso di problemi.
Esperti dei quali non hai bisogno, perche' non usi hibernate. E' piu'
facile che si abbia bisogno di un DBA.
Dai una classe java ad un DBA e dimmi che ti risponde...
lol...dai...facciamo così...la prima volta che incontri un DBA chiedigli
se ti scrive o ti ottimizza una query di una tua applicazione.
Post by Davide
Per lo stesso motivo cui e' nato tutto... Introdurre un componente in
piu' che si puo' rompere, introduce complessita' nell'architettura.
Spesso piu' le cose sono semplici, meglio e'.
E secondo te (sempre, ricordati, stiamo parlando di cose essenziali, che
non si possono togliere, al massimo sostituire), qual'è il componente
più fragile? Quello che è diffuso e testato in migliaia di contesti
diversi, o quello che è stato scritto in casa per l'occasione?

Quanto alla semplicità. Si possono usare Spring e Hibernate in maniera
molto semplice, come tipicamente qualunque cosa...ma bisogna conoscerla
molto bene, ed è questo l'apporto essenziale di un esperto.
Post by Davide
A meno che per guidarli non intendi, scrivimi questi pojo... In due
giorni non leggi nemmeno l'indice della documentazione di spring e
hibernate...
Infatti io non gli ho dato documentazione da leggere...dopo 3-4 ore di
infarinatura su Spring e Hibernate, gli ho spiegato come si fa a fare un
CRUD in una webapp già in sviluppo, e loro lo hanno fatto. Non è che
sono magicamente diventati esperti di Spring e Hibernate in due giorni:
semplicemente hanno imparato e capito le cose che gli servivano in quel
momento.
Post by Davide
Vorra' dire che un giorno offriro' una birra a te e cicap insieme,
cosi' mi spiegate come si fa a lavorare in modo produttivo...
Per una birra questo ed altro... :)
Post by Davide
Io invece vi scrivo una bella query. Basta che la finiamo con sto
thread che ormai e' diventato sterile.
Sono d'accordo. punto!

Ciao
Lucio
--
Lucio Benfante
JUG Padova http://www.parancoe.org ...have a look at it!
www.jugpadova.it http://www.jugevents.org
Davide
2011-04-07 10:07:43 UTC
Permalink
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.
Pablo
2011-04-07 16:18:25 UTC
Permalink
Post by Davide
Francamente non capisco la ragione percui ve la prendete in questo
modo...
Sinceramente posso capirli: certe affermazioni campate in aria non
piacciono neppure a me che di certo non sono un estimatore degli ORM... :-)
Post by Davide
mica vi sto insultando (IO), stiamo parlando di codice
ragazzi, trombate un po' di piu', bevetevi una birra, andate a giocare
a pallone...
Queste trollate si potrebbero anche evitare. IMO.
Post by Davide
1. Nessuno ha chiesto a nessun'altro di usare sqlrepository
Se la citi come alternativa non stupirti se viene (peraltro giustamente)
criticata.
Post by Davide
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.
L'hanno detto? Allora son d'accordo con te.
Però mi sembrava di aver letto di progetti complessi.
Poi non mi è chiaro il perché del passaggio da "ORM o JDBC" a "Hibernate
o JDBC": in mezzo vedo almeno una dozzina di gradi intermedi.
Post by Davide
4. E' gia' capitato di dover tunare una query e chiedere al DBA di
doverlo fare. Sia con hibernate che con query native SQL.
DBA dovrebbe essere "amministratore di db", non sviluppatore di db.
Son due figure ben diverse.
Un po' come chiedere a un sistemista windows di fare un'applicazione a
finestre o a uno apache di fare applicazioni web.
Poi è anche vero che in Italia questi minestroni purtroppo sono la norma.
Post by Davide
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.
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'... ;-)
cicap
2011-04-07 18:06:29 UTC
Permalink
Post by Davide
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.
Cioè siccome ci sono bug evidenti come una casa allora è meglio di
Hibernate perchè ho individuato subito tali bug GRANDI COME UNA CASA?

Ma ti leggi le cazzate che scrivi?
Post by Davide
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?
Puoi tutto, ma in genere è bene argomentare le proprie affermazioni ed
accettare le contro argomentazione senza fare gne gne o andare a chidere
aiuto alla mamma.

Altrimenti puoi sempre andare a berti una birretta o giocare a pallone
se preferisci.
Post by Davide
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..
Anche a me è capitato, una volta all'anno. Forse. Davvero essenziale
dover essere in uno invece che in due quella volta all'anno. E S S E N Z
I A L E.
Post by Davide
6. Postate un po di vostro codice di sei anni fa, vediamo se non ci
sono bug.
E perchè mai? Centra come i cavoli a merenda.
Post by Davide
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.
Direi proprio di si, anzi a maggior ragione userei Hibernate (a Spring
preferisco altri framework).
Post by Davide
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.
"All you need to create a cool web application Provides integration with
Hibernate, OpenID, Memcached... And a plugin system. "

ROTFL
Post by Davide
Ora che ci penso, non usa nemmeno maven, che orrore!
E infatti lo hanno introdotto come estensione, probabilmente a gran
richiesta:

http://www.playframework.org/modules/maven-head/home
Post by Davide
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?
Si ma questi signori sono tutti come te? Giusto per sapere.

Dimitri De Franciscis
2011-03-24 09:33:37 UTC
Permalink
Post by carmelo
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 :)
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/
news.fastwebnet.it
2011-03-27 11:54:19 UTC
Permalink
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-989d-***@e21g2000yqe.googlegroups.com...

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 :)
SoulSpirit
2011-03-29 10:39:25 UTC
Permalink
Post by Davide
Entita' Azienda, Entita' Utenti.
[...]
Post by Davide
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...
Il cmapo "azienda" puo' essere impostato per essere caricato in modalita' lazy, cosi' che venga letto dal db solo a fronte di un accesso diretto all'oggetto.
Post by Davide
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.
E' naturale che il modello dati applicativo differisca dal modello dati utilizzato per i servizi esterni, ed ha senso che web services differenti richiedano modelli differenti per le stesse entita' applicative.
Un esempio: se il tuo modello per l'utente contiene il campo "password" cosa fai, lo includi nel web service?
Post by Davide
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.
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
Davide
2011-03-30 09:09:49 UTC
Permalink
Post by SoulSpirit
Post by Davide
Entita' Azienda, Entita' Utenti.
[...]
Post by Davide
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...
Il cmapo "azienda" puo' essere impostato per essere caricato in modalita' lazy, cosi' che venga letto dal db solo a fronte di un accesso diretto all'oggetto.
Post by Davide
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.
E' naturale che il modello dati applicativo differisca dal modello dati utilizzato per i servizi esterni, ed ha senso che web services differenti richiedano modelli differenti per le stesse entita' applicative.
Un esempio: se il tuo modello per l'utente contiene il campo "password" cosa fai, lo includi nel web service?
Chiaro che non lo includi, ma non lo includi mai, percui quello e'
alla fine il problema minore... Se usi Java WS, metti un bel
@XmlTransient sul campo e hai risolto il problema.
Post by SoulSpirit
Post by Davide
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.
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.
Continua a leggere su narkive:
Loading...