Newsgroup: it.comp.java
Titolo: Framework di persistenza, qualche dubbio

Salve ragazzi,
tiro di nuovo in ballo un argomento che poco tempo fa č stato riproposto nel 
post "Utilizzo Java e databases", a proposito dell'impiego di framework di 
persistenza. Mi piacerebbe avere qualche impressione da voi sull'utilizzo di 
framework come Hibernate in cui la base di dati č preesistente e non 
progettabile da zero per sposarsi bene
con un dominio applicativo pensato ad oggetti. Purtroppo io non l'ho mai 
usato, e vorrei risolvere questi dubbi prima di lanciarmici nello studio.
Grazie a tutit,
Scorpio. 

 Scorpio.
ciao Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

Ciao,
   la tua situazione è molto comune: i framework di persistenza sono
relativamente recenti, mentre i sistemi di gestione di basi di dati
relazionali sono molto più anziani e quindi consolidati.
E' vero che iniziando a studiare Hibernate, gli autori ti propongono
la modellazione del dominio di interesse secondo il paradigma object-
oriented, per poi generare successivamente il modello relazionale: è
uno dei due approcci possibili, ed è quello ovviamente consigliato e
preferenziale.
Ma si tratta di uno strumento utilizzabile anche nel verso opposto:
dal modello relazionale al modello a oggetti. In realtà, se hai
possibilità di effettuare modifiche al modello relazionale pre-
esistente, puoi utilizzare tutte le caratteristiche di Hibernate,
compresa l'ereditarietà (Hibernate può richiederti l'aggiunta di uno o
più campi alle tue tabelle per i suoi scopi, che non vanno modificare
la semantica delle tabelle stesse. Ovviamente la gestione di questi
campi sarà quasi trasparente sia allo sviluppatore, sia a chi fruisce
della base dati con altri strumenti: il 'quasi' si riferisce al fatto
che dal punto di vista dello sviluppatore, egli dovrà utilizzare
questi campi per la mappatura, mentre chi usa la base dati relazionale
dovrà tener conto che un select *..., ad esempio, gli farà comparire
qualche colonna in più).
Se viceversa non puoi fare modifiche, come ti ha già detto Nicola, in
ogni caso puoi utilizzare comunque tutte quelle caratteristiche di
Hibernate che ti p'ermettono di rendere portabile la tua applicazione
su più rDBMS, utilizzando al tempo stesso una robusta rappresentazione
ad oggetti del tuo dominio di interesse.
Il problema è anche culturale: pur potendo partire da zero, molti
progetti modellano il dominio secondo il paradigma relazionale, e poi
ci costruiscono attorno l'applicazione, utilizzando il framework di
persistenza soprattutto per risolvere il problema della portabilità su
più rDBMS, e in secondo luogo per avere un modello di programmazione
più efficiente.
Per mia esperienza personale, nell'azienda in cui lavoro siamo sempre
partiti dal modello relazionale, per poi costruire un'applicazione
attorno: è la questione (o forse dovrei dire il limite) culturale cui
accennavo prima. L'adozione di un framework di persistenza è stata
recente, l'adozione di una nuova metodologia di progettazione che
adotti interamente il paradigma orientato agli oggetti sarà
probabilmente più lenta.
Ciao
Daniele

 usato, e vorrei risolvere questi dubbi prima di lanciarmici nello studio.
Consigli:
1) Usare l'API di JPA
Se costruisci la tua applicazione usando JPA come interfaccia avrai un 
prodotto piu' riutilizzabile, in futuro potrai cambiare back-end e 
mantenere il tuo programma inalterato.
L'API di Hibernate è compatibile con JPA quindi se adotti potrai 
comunque utilizzare Hibernate.
Potresti decidere di usare le peculiarità di Hibernate solo se ne hai 
veramente bisogno.
2) Usare cmq un framework ORM
Secondo me un framework ORM andrebbe utilizzato indipendentemente dal 
fatto che la base dati esista già.
Il vantaggio di usare un ORM non sta tanto nell'autogenerazione delle 
tabelle ma nel fatto di poter gestire i dati come oggetti (con le loro 
relazioni) piuttosto che come tuble di valori.
Accedendo ai dati usando il modello a oggetti riesci a manipolare 
programmaticamente concetti di astrazioni piu' alti (come le relazioni 
tra gli oggetti) a cui non puoi accedere direttamente con il modello 
relazionale.
-- 
Andrea Francia
http://andreafrancia.blogspot.com/2008/06/relazioni-molti-molti-con-jpa.html

Rispondo unitamente a tutti, ringraziandovi per il contributo.
Premetto che difficilmente potrò usare dove lavoro sia JPA che 
Hibernate:peccato, perchè molti di voi ne sono entusiasti e credo che 
abbiate ragione nell'esserlo; però:
a) i capi non vogliono che alcun dato sia cachato, nel modo più assoluto, 
anche perchè i l database è condiviso con altre applicazioni legacy. Ho 
studiato la JPA quando ho studiato gli EJB 3.0, interessantissima soluzione 
ma se non ricordo male il Persistence manager è in grado di "tenersi in 
pancia" gli oggetti di cui ha bisogno anche per gestire le problematiche di 
lock applicativo. Per cui se accedo dal prg J2EE ad un certo "Ordine", il 
persistence manager è i in grado perfettamente di gestire l'accesso 
condiviso (da solo o con altri pattern), come pure è in grado di scegliere 
quando memorizzare su DBMS il dato modificato. Quello che si vuole ottenere, 
nel mio caso, è il tempo reale di accesso ai dati, per cui niente cache.
b) nel dbms NON si usano mai chiavi univoche, e JPA se non ricordo male ne 
fa grande uso (cosa corretta, la stortura è nel DBMS non nell'approccio di 
JPA)
Per cui, horribili dictu, mi sono scritto un mini-framework di persistenza 
tramite JDBC, che funziona bene per quel che ci serve e ne sono contento.
Però già che ci sono mi viene da fare l'avvocato del diavolo e proporvi 
un'altra situazione...Il classico applicativo che stiamo sviluppando prevede 
una videata di filtro, quindi un approccio di gestione dei dati di tipo 
master / detail. Niente di che, ma il filtro comprende, tipicamente, almeno 
una quindicina di campi di ricerca. Ora, sempre se la memoria non mi 
inganna, usando JPA dovrei definire i vari findByXXXX....  Ma visto che non 
tutti i campi sono obbligatori, in scenari come questi non risulta una 
scelta migliore eseguire un'accesso diretto ai dati via JDBC, e solo 
successivamente usare JPA per il caricamento e la gestione del dato 
identificato dalla sua chiave (che nel mio caso è solo logica e non fisica) 
?
Altra questione. Difficilmente, per non dire : è impossibile, ci si sposterà 
dal DBMS scelto. In questo caso vale la pena ricorrere comunque ad Hibernate 
/ JPA, fatto salvo il fatto che lo strato di accesso ai dati è stato il più 
possibile isolato e reso generico rispetto al DBMS di riferimento ?
Saluti,
    Scorpio. 

 possibile isolato e reso generico rispetto al DBMS di riferimento ?
Il vantaggio degli ORM non sta tanto nell'astrazione dal dialetto SQL 
dei DB sql (che comunque non è un vantaggio da poco) ma quanto nella 
possibilità di cambiare il modello dei dati, da relazionale (piu' vicino 
al modello fisico) a oggetti (piu' vicino al modello concettuale).


 DAO.
Beh, pensavo che una query diretta fosse più efficiente rispetto al passare 
attraverso un persistence manager, vedi ad esempio il pattern Fast Lane 
Reader per gli EJB 2.1


 Reader per gli EJB 2.1
Non conosco il pattern Fast Lane Reader.
Io non darei per scontato che la query sia piu' lenta, o che comunque la 
differenza di velocità sia misurabile. Di solito queste ottimizzazioni 
si fanno dopo aver misurato le performance e aver concluso che non sono 
accettabili.



Ciao
Se ti vietano hibernate amen :-|.
Quello che ha scritto Francia e' gia' abbastanza esaustivo.
Quello che e' importante e' che gli Architetti che scartano hibernate
perche' lo considerano una cache che minaccia la concorrenza, purtroppo
"stanno fuori" :-)). L'affermazione e' completamente falsa, a mio avviso.
Trovino un articolo qualsiasi che presenti il problema,
la Persistenza fa si che i singoli oggetti vengano cercati prima in memoria
e poi su db.
Qualora ci fosse un punto a rischio concorrenza ci vorra' per forza un
manager di concorrenza ( come gia' ha detto Francia, e siamo gia' 2 ) che
forzera' le "flush" delle query e garantira' la atomicita' delle
transaction.
La strada piu' pulita' e' usare Hibernate in EJB3 Entity chiamati da EJB
Session che hanno la JTA incorporata e dovrebbe garantire gia'ì da sola
l'atomicita' della query , ma di questo mi dovrei documentare meglio e puo'
essere che va gestita a mano la transaction su db
Tutti questi problemi non vengono assolutamente risolti TOGLIENDO hibernate
e usato jdbc ( anche hibernate usa ovviamente jdbc )
Per chiarire meglio queste sono alcune delle feature di hibernate :
1. Persistenza , che ho chiamato cache nell'altro post in modo forse
semicorretto.
2. VIsione dei dati a oggettti anziche' record
3. Uso di HQL
4 ereditarieta'
5. Portabilita
6. gestione ID
7 ....
In reverse perdi ereditasrieta' e basta
La portabilita' serve a poco o nulla perche 99% progetti nascono e muoiono
su un db
I vantaggi stanno nel punto 2 e 3 e sono :
a. Applicazione piu' pulita, elegante manutenibile, leggibile ecc
b. HQL >>>>>>>> SQL, quindi
    Query moooooooooooooooolto piu' semplici, anche da 1 pagina a 2 righe
c. SPARISCONO LE UPDATE
d. SPARISCONO LE INSERT
e. SPARISCONO LE DELETE
f. ........ ora non mi viene in mente altro ma ce ne e' da vendere
Poiche' spesso a chi decide "nonglienepuo' fregaredimeno" di questioni cosi'
prettamente tecniche possiamo pero' dirgli che dai punti a->e
=====>
APllicazione scritta in
MENO TEMPO/SOLDI,
MENO ERRORI = + UTILE / - PENALE,
PIU' FACILE MANUTERLA = MAGGIORI MARGINI DI GUADAGNO SU OGNI INTERVENTO
MANUTENTIVO
quindi se hai architetti poco ragionevoli e' solo sfiga.
Posso dirti che 2 anni fa sono stato chiamato a supportare l'introduzione di
Hibernate in BPM e c'erano 100 tabelle circa ( solo per un gruppo di
applicazioni ) e gli costo' un botto la migrazione
piu' tardi lo inserisci peggio e', ma l'idea di avere in circolazione i
resultset jdbc sinceramente e' veramenbte poco professionale per una
applicazione seria
Ciao Nicola
<CUT>


relazioni) piuttosto che come tuble di valori.
"Tuple", forse. Comunque sul fatto che questo sia un vantaggio, c'è
tanto da discutere. A mio avviso, si può fare a meno di un ORM in
moltissimi casi (e personalmente non mi stanno molto simpatici). Il
modello ad oggetti, applicato ad una base dati, può creare diverse
idiosincrasie. Secondo me bisogna valutare bene come e quando usare un
ORM.


A presto e grazie,
    Scorpio. 

 Scorpio.
Nicola


 l'univocità del dato.
   Ma veramente non hanno chiavi? Mi sembra impossibile. Magari non 
hanno chiavi surrogate. Mi puoi fare un esempio di tabella del tuo DB 
che non ha chiavi?
   Ho l'impressione che tu possa usare il termine 'chiave' al posto di 
'chiave surrogata', se è questo il caso allora puoi comunque usare JPA.
   Se mi fai vedere la definizione (ad es. in forma di script CREATE 
TABLE) di una tabella del tuo DB che secondo te non ha chiavi posso 
indicarti come usarla in JPA.


 come usarla in JPA.
Va bene un CREATE TABLE PERSONA (CODFISCALE CHAR(16), NOME VARCHAR(50), 
COGNOME VARCHAR(50)) per rendere l'idea ? Certo, esistono chiavi logiche 
(unicità in questo caso di CODFISCALE) ma va gestita integralmente a 
programma.
Non ho idea di che siano le chaivi surrogate: puoi spiegarmelo  ?
Scorpio.

 Nicola
Ciao,
    Scorpio. 

 
-- 
Andrea Francia
http://andreafrancia.blogspot.com/2008/07/colinux-linux-dentro-windows.html

 programma.
La domanda sorge spontanea: perchè?
Y.

 programma.
A parte l'ovvia idiozia di chi ha create il database (ma sinceramente
nella mia esperianza professionale non ho mai incontrato database con
constraints ben fatte), Hibernate se ne frega se la chiave primaria e'
tale in quanto definita con PRIMARY KEY oppure se e' supposta essere
tale dell'applicazione.
Tu basta che gli dici quali sono i campi che formano la chiave
composta.
Certo, il tutto funzionerebbe molto meglio con chiavi surrogate
(chiavi non di business, ad esempio ID), ma lavorando con database pre-
esistenti si sa che ci si deve adattare.



Visto che si discute di chiavi e hibernate confermo che Hibernate lavora
meglio con quelle che voi chiamate CHIAVI SURROGATE ( termine che non
conoscevo ) , che poi di fatto di solito sono gli id numerici delle
sequence.
Questo e' dovuto al fatto che le chiavi composte richiedono la creazione
della classe Primary key che poi da dei fastidi pratici un po' dappertutto,
anceh se comuqnue io ogni tanto le uso.
Da un punto di vista teorico questo e' un peccato perche' le chiavi
surrogate degradano la qualita' del database ( innanzituto in leggibilita' )
ma non dovrebbe essere difficile dimostrare che dovrebbe quasi sempre
degradare anche la FORMA NORMALE del database.
Comunque io ci ho messo una pietra sopra ormai e faccio un id sequence per
ogni tabella e amen.
L'unico vantaggio e' che e' tutto editabile. Comuqneu vedo nei progetti open
source che in tutto il mondo sono rassegnati a mettere chiavi surrogate
ovunque, purtroppo
Ciao Nicola


 ovunque, purtroppo
Rassegnati? Secondo me invece finalmente ci si è accorti che avere 
chiavi primarie troppo complicate e database troppo normalizzati fa solo 
la felicità dei DBA, ma è deleterio per lo sviluppo delle applicazioni, 
sia in termini di complessità dello sviluppo, sia per la loro 
efficienza, sia per la loro evoluzione e manutenibilità nel tempo.
Ad esempio, rimanendo nel caso delle chiavi, quanti esempi di chiavi 
naturali conoscete, che possano essere usate come chiave primaria al 
posto di una qualunque chiave surrogata? Il primo che mi viene, già 
citato nel thread, è il codice fiscale per un'entità persona...pessima 
idea: ve la immaginate l'efficienza del database a fare join su join con 
tale entità? O la complessità di scrittura di un'applicazione che debba 
gestire anche le modifiche di tale valore (sì...perché gli utenti 
possono addirittura sbagliare a scrivere :) ). Quindi, al di là della 
teoria dei database relazionali (che è bene comunque conoscere), nella 
pratica si scopre che è meglio usare delle chiavi surrogate, e 
possibilmente anche molto leggere e facili da gestire.
...my 2c...anzi...visto che i cents ci sono anche in Italia...i miei 2c :)
-- 
Lucio Benfante
JUG Padova           
http://www.parancoe.org
 ...have a look at it!
www.jugpadova.it
 
http://www.jugevents.org

 degradare anche la FORMA NORMALE del database.
Direi che la normalita' del database e' al sicuro con le chiavi
surrogate.
Se ti riferisci, ad sempio, al fatto che voui assicurarti che la
username sia unica, beh hai anche la constraints UNIQUE alla quale
puoi (anzi dovresti) ricorrere.
Come dici non hai problemi a modificare la username ad esempio.
Inoltre eliminando la possibilita' di chiavi primarie composte i
corrispettivi campi chiave esterne sono sempre e solo composte da una
solo semplicissimo campo.
Certo ha i suoi svantaggi: non ti devi dimenticare la constraint
UNIQUE quando e' necessaria Inoltre una chiave di business puo'
offrire vantaggi in alcune query (generalemnte invece accade il
contrario), si tratta di trucchetti pero'.

 
www.jugpadova.it
 
http://www.jugevents.org
Ciao Nico


 surrogate.
Per la teoria dei database e delle FORME NORMALI degrada da Boyce a 4 a
..... a non normale
comuqnue non ho la minima voglia di andare a ripassarmele le FN quindi
potrei pure sbagliarmi :-), anche se a naso dovrebbe degradare con le
surrogate, vedi anche risposta a Lucio.


 surrogate, vedi anche risposta a Lucio.
Lucio dice solo che se ne frega della BCNF. Non che per forza l'uso di
chiavi primarie surrogate degradi la forma.
A naso invece credo proprio che se usi sempre le surrogate hai una
quarta forma banale. Banale nel senso che e' per forza cosi': usi
sempre e solo una colonna univoca come chiave. Che violazioni dovrebbe
dare?
Formalmente e' perfetto, si puo' invece obiettare che la chiave
primaria non dia in se informazioni significative sul contenuto del
record (a cui puoi ovviare con UNIQUE).

 autoincrementante.
Tipo VersionID pattern ?
Scorpio.

 Scorpio.
Nicola


 
Non capisco bene quale sia il problema, comunque l'unicità delle chiavi 
è gestita da JPA (a patto di fornire una IdClass o una EmbeddedId corretta).


 vai posta tutto, tanto immagino che saranno poche righe
Mica tanto, c' è tutto un discorso dietro.... comunque grazie per i 
consigli.
Scorpio 

 Scorpio
 
ciao Nicola


 altre strade.
Accetto le tue critiche, che mi sembrano documentate. E' vero, il framework 
che
ho scritto è casereccio (io preferisco il termine artigianale :-) ), epperò 
ti posso assicurare
che è in produzione da un paio d'anni e non ha mai dato rogne. Ciò non 
significa nulla,lo so,
ma è almeno un po' di conforto....
Comunque ho capito che  Hibernate o JPA devono essere patrimonio di chiunque
lavori seriamente in Java/J2EE, e pertanto mi documenterò seriamente su 
questi aspetti,
approfittando delle ferie :-).
Magari a settembre tornerò....alla carica e ne riparliamo con più cognizione 
di causa (da parte
mia, naturalmente!) sull'argomento.
Ciao !
    Scorpio.

 record (a cui puoi ovviare con UNIQUE).
L'argomento e' parecchio interessante.
Rimando la continuazione a dopo che mi saro' bene ripassato le 4+1 forme
Normali, per evitare discussioni poco scientifiche, sperando che non passino
troppi anni.


Ciao, io sono Alessandro Saitta di 39 anni a Follonica-GR (Toscana),
in via Cassarello 131! Puoi vedere la  mia video presentazione da
qui:
http://saitta.badoo.com/e78433
Sito web: 
http://saiita69.altervista.org
Profilo Badoo: 
http://saitta.badoo.com/
Profilo Netlog: 
http://it.netlog.com/IL_SAITTA1969
Profilo DammiSpazio: 
http://www.dammispazio.com/utente/Alessandro_Saitta
Vieni a visitare il mio profilo!!! Cerca 'Alessandro Saitta' su
Google, YouTube e  Libero Video!
Aggiungimi: MSN messenger: 
Saitta_...@hotmail.it
 - Yahoo
messenger: saitta_alex1969 - Skype: alessandro_saitta
Cellulari: 340 9397083 - 327 1618899
E' uscito 'Video Disco Saitta 2008'! Girato in spiaggia a Follonica e
con la partecipazione straordinaria di Ermir Subashi (http://
it.netlog.com/thermis
)! Puoi vederlo da qui:
http://it.youtube.com/watch?v=jELF-9RmDUo