Post by DavideCiao 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 DavideEntrambe 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 DavideNemmeno 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 DavideOra 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 DavideCaro 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 DavideRipeto, 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 DavidePer 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 DavidePurtroppo 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 DavideSi 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 DavideChi 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 DavideTutto 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 DavidePost by Lucio BenfanteOvvio 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 DavidePerche' 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 DavideOrmai 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 DavideAll'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 DavidePost by Lucio BenfanteL'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 DavideIo 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