Newsgroup: it.comp.java
Titolo: Un ORM tool è utile con poche o tante classi?

La domanda di cui all'oggetto deriva dalla considerazione postami da una
persona, secondo cui un tool di mapping relazionale è utile in
particolare con poche classi in gioco. 
Sebbene stia muovendo ancora i primi passi con Hibernate, avendo
sviluppato in precedenza delle soluzioni fatte in casa, mi sono trovato
a rispondere che secondo me un tool ORM è più utile quando le classi
sono tante, perché sebbene - nel caso artigianale - un minimo di
infrastruttura va realizzato anche per poche classi, quando diventano 
tante il codice di gestione diventa davvero molto, per non parlare poi
di cosa accade in caso di refactoring, che ti porta a modificare il
codice SQL.
Mi piacerebbe avere le vostre osservazioni in merito.
La risposta "un tool ORM è sempre utile" la eviterei :), perché certo,
una volta imparato ad usarlo tutto sommato lo si può usare anche per una
sola classe, ma con ciò che ho scritto intendo capire in quale
situazione sia PIU' utile.
-- 
Herbie


Salve a tutti,
forse la risposta "un tool ORM è sempre utile" è sbagliata ....... ma
non al 100%.
Il mio pensiero è che nella programmazione un tool è importante per
questi motivi:
- quando siamo di fronte ad operazioni ripetitive un tool è la giusta
risposta;
- un tool aumenta la standardizzazione del codice soprattutto se allo
stesso progetto partecipano più persone;
- se recupero del tempo usando un tool, posso utilizzare il tempo
risparmiato per miglorare la logica del programma;
- un tool è meno soggetto ad errori o dimenticanze perché il codice è
generato automaticamente.
Nel caso specifico di un ORM lo considero utile soprattutto per
progetti complessi. Però, se il tool fosse flessibile al punto di
poterne usare una parte, quasi una modalità "semi-automatica" non ci
vedo nulla di scandaloso. Anche perché il fine giustifica il mezzo.
Anch'io sono alle prese, da pochissimo, con Hibernate. Di solito mi
diverto a costruire ciò che non esiste. Ma quando non saprei fare di
meglio o al massimo otterrei lo stesso risultato, non ha senso
irrigidisrsi in soluzioni proprietarie ed artigianali.
Biagio

 wrote:

A parte che 'tante classi' non mi sembra un buon modo di classificare
un programma (occorre vedere come queste sono ripartite) partendo dal
presupposto che un ORM faccia risparmiare tempo e fatica, mi sembra
alquanto ovvio che maggiore è la complessità (IMHO del DB) maggiori
sono i benefici nell'usare un ORM. Sempre a patto che non ci siano
problemi di impedance mismatch
Io sono arrivato al punto (usando un ORM 'fatto in casa', ma complesso
e potente forse più di hibernate stesso), che senza probabilmente non
saprei nemmeno come fare a programmare!

 ha scritto: 
Sarei curioso di sentire dal Signore che ha sparato la toeria se la sa
argomentare un po'.
L'ORM framework serve 
a. ad avere un programma piu' leggibile e manutenibile, il che avviene sempre
indipendentemente dal numero di calssi 
b. a utilizzare un db relazione come fosse un db a oggetti con ereditarieta'.
Il che e' sempre utile per la qualita' del codice. Potrebbe dare problemi di
prestazioni, ma sono ottimizzabili e inoltre l'ereditarieta' puo' essere
spinta di piu' o di meno in fase di progettazione.
c. ad avere una cache di primo livello, il che e' utile in caso di singola
JVM.
d. ad avere una cache di 2. livello, il che e' utile in caso di un cluster,
purche' l'overhead della cache non superi i vantaggi ottenuti ( il che non
dipende dal numero delle classi in gioco )
c. e d. danno svantaggi in caso ci siano altre applicazioni che operano sui
dati, il che non e' correlato in alcun modo al numero di classi.
Queste sono le considerazioni piu' immediate che mi vengono in mente e non
trovo alcun ragionamento correlato al numero di classi.
ciao Nicola
-- 

 dipende dal numero delle classi in gioco )
Guarda che la cache di primo livello ha uno scope transazionale a 
differenza di quello di secondo livello.
Quella di primo livello è utile sempre non solo fuori da un cluster.
Stesso discorso per quella di secondo livello: è molto utile con o senza 
cluster (ovviamente meglio senza cluster come qualsiasi cache).

Il 05/09/10 14.24, Herbie ha scritto:

beh posso darti la risposta che desideri se mi dici quale :)
il fatto è che a prescindere dalla complessità (che tu misuri in numero 
di classi, vabbeh) la business logic del tuo programma java avrà sempre 
bisogno di lavorare sui dati in qualche modo rappresentati come oggetti 
java. se poi il database è semplice meglio, vuol dire che l'accesso ce 
l'hai gratis. se c'è un problema non è su gradi di complessità bassi ma 
semmai su schemi database complessi e non correttamente disegnati con 
logiche relazionali, come ad esempio avviene nella migrazione da altri 
linguaggi. ma se uno parte da situazione pulita non ci sono reali motivi 
per non approcciare l'accesso ai dati con logica orm.

 per non approcciare l'accesso ai dati con logica orm.
Per quanto mi riguarda il db lo devo creare insieme al programma, quindi
in teoria posso lasciarlo creare direttamente ad hibernate. Ma
considerato che avevo già sviluppato un po' di schemi E-R, controllerò
che hibernate generi qualcosa di simile e che mi piaccia, e se scriverò
bene i mapping, così dovrebbe essere
-- 
Herbie

 problemi di impedance mismatch
La risposta che mi aspettavo alla mia domanda era in pratica questa,
cioe' mi sembrava logicom, ma essendo entrato nel mondo ORM da poco non
potevo affermarlo con certezza. 
C'è da dire, comunque, avendo creato un po' di codice di persistenza a
mano, che parte della complessità c'è inizialmente per metter su dei
meccanismi di base utili per ogni classe che si vuol persistere, ma
certo ogni classe ha bisogno delle sue specifiche query e dello
specifico codice che mappa i campi db in quelli delle classi
-- 
Herbie

 trovo alcun ragionamento correlato al numero di classi.
Questo è vero, è che la questione nasceva dal decidere se, non
conoscendo tool ORM, fosse il caso di impararne uno per gestire "poche
classi" o scrivere codice ad hoc. Nella fretta, l'ultima soluzione non
la scarterei del tutto, ma è chiaro che, anche in un'ottica futura,
conviene delegare all'ORM tool la persistenza
-- 
Herbie

bene i mapping, così dovrebbe essere
Una volta preso confidenza con Hibernate non e' che hibernate si beve una
bottiglia di rum prima di fare il db :-))
Il db viene ESATTAMENTE COME TU LO DESIDERI, basta solo che ti studi le varie
JOIN-TABLE ( se usi ereditarieta' , ma puoi pure farne a meno ) e le relazioni
N-1 che ti generano l'E-R come lo vuoi tu.
posso capire eventualmente che per motivi di super-fretta ignori ogni forma di
pattern e mappatura e , come dici te, scrivi query SQL dirette, in questo caso
puo' essere che per una applicazione poco complessa risparmi tempo e fatica.
ciao Nicola
-- 

 giornata di studio di hql per poterlo usare nelle funzionalita' base.
Diciamo che mi sono trovato con la necessità già di estenderlo, vi
UserType e forse dovrò con UserCollection, e capire quell'aspetto non è
stato proprio immediato. In particolare, non mi pare che il manuale
parli della UserCollection, bisogna di fatto andare a vedere i sorgenti
HB
-- 
Herbie

 HB
? non capisco
se ti va di parlarne puo' essere interessante
mi e' capitato di modificare sorgenti di struts di liferay e altro, ma di
hibernate davvero e' singolare.
Tieni presente che se usi hibernate ( JPA ) con ejb3 sun sono pure non
modificabili perche' non sono OS
quindi non e' una buona idea a mio avviso estendere hibernate perche' ti
giochi la portazbilita' ejb3
a meno che non ti metti a reintegrare pezzi interi di app server ...
ciao NIcola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 modificabili perche' non sono OS
Peraltro se si implementa la persistenza per una collezione non standard
non si può usare JPA, perché da mie ricerche supporta quelli che HB
chiama UserType, ma non le collezioni non standard
Parlavo di estendere HB nel modo "canonico" e previsto da loro, diciamo
esternamente, implementando l'interfaccia, sen non ricordo male,
UserCollectionType e PersistentCollection
-- 
Herbie

 ha scritto nel messaggio 
news:slrni872u...@tux.homenetwork...
