Newsgroup: it.comp.java
Titolo: Motori di persistenza e OOP

Salve a tutti.
Mi rivolgo in particolare a chi già utilizza il motore di persistenza OJB.
Perchè ojb (ma anche gli altri motori come hibernate?) accede alle
proprietà private di un oggetto direttamente? Non tradisce l'OOP?
Ineffetti, a causa di ciò, mi sto trovando in un bel casino.
Ciao,
GianpieroP 
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Ineffetti, a causa di ciò, mi sto trovando in un bel casino.
Di che genere?
pole
-- 
ammentos - a lightweight persistence framework for JDK5
http://www.sourceforge.net/projects/ammentos
http://ammentos.biobytes.it

 Di che genere?
Campo data!!
Il form-bean di struts tratta la data come stringa, OJB la deve trattare
come java.sql.Date. Vorrei utilizzare un unico attributo privato e
wrapparlo con una coppia di accessor method per stringa e un'altra per
Date.
A causa di OJB devo necessariamente scegliere di utilizzare l'attributo
privato come Date. Il setDataAsStr(String strData) tenta una conversione
con il SimpleDateFormat, se non vi riesce, imposta a null l'attributo
privato Date data. Il validator di struts non riesce a discriminare se
l'utente ha inserito male il campo data (formato errato) o non l'ha
inserito affatto (campo obbligatorio). Il validator, in entrambi i casi,
legge null e quindi lancia il messaggio "Campo Obbligatorio!!".
Se invece avessi utilizzato l'attributo privato come String, avrei potuto
conservare l'informazione completa (null, stringa formattata male, stringa
formattata bene). Invece adesso devo introdurre un altro attributo che
completi l'informazione non ottenibile con il solo attributo Date data: è
una pessima soluzione.
In ogni caso ti ringrazio per il tempo dedicatomi.
Ciao,
GianpieroP.


 In ogni caso ti ringrazio per il tempo dedicatomi.
Figurati, spero di averti dato qualche spunto :)


 Figurati, spero di averti dato qualche spunto :)
Sicuramente mi hai "richiamato all'ordine" suggerendomi di utilizzare il
tipo appropriato allo scopo. Ineffetti hai ragione: dovrei utilizzare il
tipo Date, ma forse non ho ancora assimilato bene il fw struts, perchè non
saprei come discriminare tra i due casi di errore: obbligatorietà e
sintassi del formato.
Grazie,
GianpieroP 


 3) Accessor Methods (di cui ti parlavo già nel precedente post).
 > Gli accessor methods mi consentirebbero di mediare tra il mondo
 > esterno e
 > gli attributi interni dell'oggetto.
E' la scelta di Hibernate. Personalmente (ma sicuramente molti non la 
pnsano come me) non mi piace molto come soluzione perché sono abitutato 
a pensare agli oggetti, in termini di OOP, come dati + metodi. I dati 
per come la vedo io sono quelli "grezzi", contenuti dentro le variabili, 
che rappresentano lo stato interno dell'oggetto e che IMHO dovrebbe 
essere  "fotografato" senza interferenze intermedie.
Per esempio, anche se una variabile interna myDate può per qualche 
motivo essere impostata a null, è perfettamente leggittimo che un metodo 
setMyDate() non accetti valori null. In questo caso un fw di persistenza 
che lavorasse sui soli accessor non sarebbe in grado di ricostruire 
correttamente lo stato interno di un tale oggetto.
ciao :)


 2) Violi l'incapsulamento e li gestisci anche se privati.
ciao,
 scusate l intromissione ma mi interessa la parte della discussione riguardo
i campi privati/pubblici sul
scusa, pole, forse nn ho capito qual'e' il tuo problema del campo
privato/pubblico:
ritengo che entrambe le tue soluzioni proposte siano *sbagliate*: l usare
getter e setter e campi privati? poi come fai ad accedere al di fuori della
classe ai campi privati di un oggetto?
ti ripeto, forse mi sfugge qualcosa...
ciauz ;)

 mi sono trovato nella situazione di dover effettuare questa "violazione".
Ciao,  anch'io mi sono cimentato nell'impresa di scrivere un piccolo
persistence engine...
posso chiederti che soluzioni hai adottato allo scopo ?
Scorpio.

 Avendo scritto, nel mio piccolo :-), un motore di persistenza anch'io, 
ci ho dato uno sguardo, complimenti! Mi sembra buon codice (ThreadLocal al
posto giusto, ecc.)
Secondo me dai dei punti a Hibernate.
ciao
uL


 Secondo me dai dei punti a Hibernate.
Ehm... sono senza parole! Grazie mille... :)


 posso chiederti che soluzioni hai adottato allo scopo ?
Ciao Scorpio.
Ammentos è il risultato di varie soluzioni, più o meno buone, da me 
adottate nel corso degli anni. In particolare il grosso del codice 
proviene dal refactoring di un miniframework che avevo scritto l'anno 
scorso, che però girando su JDK1.4 aveva grossi svantaggi rispetto a questo.
A grandi linee l'idea che sta alla base del progetto è l'associazione di 
una classe Metadata ad ogni classe persistente. Un'istanza di Metadata 
contiene tutte le infomazioni utili per gestire la persistenza degli 
oggetti. La persistenza vera e propria degli oggetti è però delegata ad 
un insieme di oggetti Persistor; finora l'unico implementato è il 
DatabasePersistor, in grado appunto di gestire la persistenza degli 
oggetti su database.
Di soluzioni ne ho addottate parecchie per gli scopi più disparati, cmq 
i sorgenti sono liberamente disponibili su licenza GPL.
Ciao!


 ciauz ;)
Ciao!


 scorso, che perň girando su JDK1.4 aveva grossi svantaggi rispetto a
questo.
Ciao Pole,
la tua soluzione mi sembra interessante... quello che avevo fatto io
funzionava in maniera simile: il motore di persistenza č un  EJB stateless
che riceve,come parametro, una classe di persistenza che esponeva alcuni
metodi per stabilire la corrispondenza attributi  / campi DB e le chiavi
primarie; via reflection, l'EJB esegue insert, update e select. L'uso degli
EJB mi consentiva di ottenere una gestione "semplice" delle transazioni.
Purtroppo, dovendo utilizzare il tutto in ambito websphere, non potrň
utilizzare Java 1.5 che ha reso, con i metadati, il meccanismo di cui sopra
molto piů "semplice" da realizzare...
Inoltre, credo che quando avrň a disposizione un app server con EJB 3.0,
butterň a mare il mio engine...
Grazie per le info !
Scorpio.