Newsgroup: it.comp.java
Titolo: Iterazione Oggetti java e tabelle DB

Ciao a tutti,
vi espongo subito il mio dubbio.
Sto creando un applicazione di magazzino che si appoggia appunto ad un
DB postgres.
Quello che volevo sapere è come potevo interagire con esso...mi spiego
meglio.
Ho creato delle classi tipo CLIENTI, FORNITORI e così via che appunto
rappresentano la tabella sul db e all'interno tutti i metodi per
interagire compresi i metodi getter e setter.
Quando devo prelevare delle informazioni creo un oggetto passandogli
per esempio l'id del cliente ed automaticamente attraverso il metodo
caricaDati() recupero tutte le info dalle tabelle memorizzandole
nell'oggetto che rappresenta la tabella e con i metodi getter e setter
recupero e modifico le propieta della tabella..mentre poi quando devo
modificare qualcosa uso i metodi setter e alla fine uso un mio metodo
update che appunto inserisci gli aggiornamenti.
Quello che mi chiedo e se mi conviene usare appunto dei metodi
caricaDati(), insert() e update() impostando prima i dati (o
modificandoli) con i metodi getter e setter oppure inserire
direttamente nel metodo setter il codice che una volta impostata la
proprietà la inserisci direttamente nel db (senza aspettare il metodo
insert), e nei metodi getter il codice per prelevare le info dal db
senza usare il metodo caricaDati().
Spero di essere stato un pò chiaro.
Grazie.
PS.:se ci sono altri metodi e suggerimenti grazie.

 DB postgres. Quello che volevo sapere è come potevo interagire con 
 > esso...
 >
Io passerei direttamente a JPA o a Hibernate, due tecnologie per il 
mapping automatico (e trasparente!) di oggetti su DB
Al meeting di luglio abbiamo parlato di JPA:
http://www.jugtorino.it/vqwiki/jsp/Wiki?MeetingLuglio2007
In ogni caso vedi anche qui:
http://www.jugtorino.it/vqwiki/jsp/Wiki?LibriGratuiti
Comunque di risorse è piena la rete :)
Ciao,
     Bruno
P.S.
Occhio ai meeting del JUG Torino!
http://www.jugtorino.it/meeting
-- 
| Bruno Bossola
| A Java Software Engineer :-)
| 
http://digilander.iol.it/bbossola
| Coordinatore del JUG Torino - 
http://www.jugtorino.it

 Quello che volevo sapere è come potevo interagire con esso...
Ti regalo la mia esperienza. Riguarda un progetto su un sistema di gestione
per centri di medicina estetica. Deve gestire i pazienti da un punto di
vista anagrafico, medico, di trattamenti ricevuti e, cosa molto importante,
poter stabilire dei "checkpoint" nell'arco di un progetto in cui i
risultati via via conseguiti siano valutati fotograficamente.
Il database(anch'io postgreSQL, per scrupolo lo faccio girare sia su Linux
che su quell'altro) prevedeva in origine 54 tabelle. A seguito
dell'accorpamento di alcune tipologie banali dentro membri final delle
classi del mio modello(che so, la tipologia dei contatti o il tipo di
mestruazioni di una donna sono cose che difficilmente saranno stravolte nei
prossimi 30 anni) le tabelle sono scese a 44.
A questo punto hai due strade. Applichi il design pattern "Data Access
Object"(DAO):
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
E crei a manina tante classi DAO specializzate sul tuo database relazionale
che si occupano di gestire le tue "entità". Affascinante, no?
Oppure, lasci che sia un motore di persistenza che, per mezzo di massiccio
uso di Reflection e guidato da file di configurazione che compilerai in
maniera più o meno manuale, si occupi del trasferimento. Cos'è la
Reflection? Per farla breve è un meccanismo per manipolare le classi,
sapere quali sono i metodi e le proprietà, il tutto a tempo di esecuzione.
Un motore di persistenza, come Hibernate, interroga le classi e sa cosa
farne perché nei file di configurazione ne mappi le proprietà sui campi
delle tabelle.
Quando ho iniziato il mio progetto ero poco più giovane, ma molto più
inesperto. Prevedevo non sarei arrivato ad imparare Hibernate a sufficienza
per portarlo in produzione. Dunque ho creato tanti DAO. Con la premessa che
un motore di persistenza è un programma che in fondo non sbaglia mai, ti
racconto le trappole più comuni nella creazione di DAO per 44 tabelle.
1) Che metodi dare ad un DAO? Ciascuno contiene i metodi base per il
trasferimento di oggetti Java da e verso il db, come ad esempio
long insert(Oggetto o)
boolean update(Oggetto o)
Oggetto find(long key)
boolean delete(long key)
Collection<Oggetto> select(Oggetto criteria)
Più i metodi che ti possono essere utili(che so, io ho un
selectProgettiByPaziente(long codPaziente) da qualche parte)
2) Devi trovare la strategia giusta per l'accesso. Un errore grave che ho
fatto è stato quello di lasciare che ogni istanza di DAO aprisse una
connessione verso il db. Ciò è profondamente sbagliato. Infatti, cresciuto
il progetto(come sviluppo) oltre una certa soglia, il limite di 100
connessioni scritto nei file di configurazione di postgres si è imposto
prepotentemente. Alla fine ho ristrutturato il tutto: i DAO sono Singleton
http://it.wikipedia.org/wiki/Singleton
 (con annesso esempio Java)
inoltre qualcuno si preoccuperà di fornirgli una connessione. Alla fine con
quattro connessioni mordi e fuggi tengo in piedi il programma, ma in fondo
con una me la cavavo lo stesso.
3) Usa il model view controller in una qualunque forma, ma usalo.
Disaccoppia il codice dei DAO, delle viste(uso javax.swing.*) e permetti la
comunicazione per mezzo di uno strato di controllo, fosse anche solo un
oggetto che delega ai DAO.
4) Fai uso di PreparedStatement che riempirai con i parametri giusti presi
dai tuoi oggetti piuttosto che concatenare a mano singoli pezzi di uno
statement. Lascia che sia il PreparedStatement a pensarci.
5) In una tabella con circa 30 campi è facile distrarsi creando un metodo di
DAO. Questo da solo è fonte di grande frustrazione e grande rimpianto per
essere stati tanto avventati da non usare Hibernate, occhio.
Concludo con gli unici lati positivi. Primo: se ti piace pigiare tasti, in
fondo a me si, ripetere 44 volte codice simile può essere divertente. Per 
primi 5-6 dao, che dovrai testare se non vuoi sorprese.
Secondo: mostrare al cliente un dao da 600 righe(righe vuote incluse)
potrebbe giustificargli un cospicuo investimento.
Conclusione mia: programmerò una migrazione ad Hibernate con tanto di branch
su Subversion(usalo, è utile tornare indietro di tanto in tanto, anche solo
per vedere come funzionava IERI qualcosa che ieri funzionava e oggi no)
appena terminato il progetto attuale.
Ciao!


Scusa ma non stai usando un pool di connessioni?
Inoltre non e' che al crescere del numero dei DAO il problema peggiora, 
perche' solitamente ne viene chiamato sempre 1, 2 per richiesta (certamente 
non centinaia di DAO). 

 Scusa ma non stai usando un pool di connessioni?
Adesso si. Il problema prima stava nel fatto che ogni invocazione del
costruttore del DAO apriva una connessione. Questa è stata una leggerezza
che ho voluto segnalare all'OP affinché la eviti.

Grazie a tutti,
ora provo a vedere un pò il funzionamento di hibernate...avete per
caso qualche tutorial online da consultare (possibilmente in italiano
per cominciare)?
Oltre ad hibernate esiste qualche altro motore di persistenza magari
con caratteristiche diverse?
Un mio amico mi ha consigliato Castor oppure di usare direttamente le
api di Java.
Grazie a tutti...
...comunque ora essendo già in una fase avanzata completerò il tutto a
manina e poi successivamente mi metto all'opera per la versione nuova
con l'uso di hibernate.
Grazie.

 ha scritto nel messaggio 
news:fbblck$i19$1...@tdi.cu.mi.it...

Quindi e' stato risolto cambiando la factory delle connessioni (che ora si 
appoggia ad un pool di connessioni), oppure cambiando radicalmente 
strategia.
Quello che voglio dire e' che puoi continuare a *chiedere* la connessione 
nel costruttore, se questa viene da un pool.

ciao,
se ti serve che la tua applicazione sia semplicemente un interfaccia verso 
il db, potrebbe anche andar bene come l'hai fatta.
Se vuoi dargli invece un'entità di applicazione meglio strutturata, e 
sopratutto di "applicazione", dovresti cominciare a pensare a eliminare il 
database :-) No beh, un pò è una battuta, ma il concetto è che 
l'applicazione deve lavorare su un dominio che modella il tuo problema, tale 
dominio lo implementi con classi java (oggetti) che realizzano le tue 
funzionalità (Cliente, Fornitore, etc).
Il fatto che ci sia un database e che i tuoi oggetti vengano persistiti su 
di esso è solo un aspetto strumentale finalizzato soltanto alla 
persistenza/salvataggio/lettura dei dati, null'altro.
Voglio dire che l'applicazione, una applicazione, dovrebbe essere cognegnata 
in generale per funzionare indipendentemente dall'esistenza di un database. 
Anche perchè mettiamo ad esempio tu potresti scegliere di persistere i tuoi 
dati su un filesystem, oppure di non persisterli e lavorare in memoria 
addirittura.
Quindi in quest'ottica è sicurametne scorretto infilare il codice di 
persistenza all'interno delle tue classi funzionali.
Il codice di persistenza è parte non funzionale, tienilo separato dalla 
logica di businiss funzionale rappresentata dal tuo dominio.
Il suggerimento di usare dei DAO è corretto, in essi metti la logica di 
persistenza.
Poi avrai il tuo "model" applicativo (il dominio) con i tuoi oggetti, che 
potranno avere dati e comportamento insieme oppure separati (il dato nudo e 
crudo lo tieni in un value object Cliente, mentre la logica la tieni in un 
ClienteBusinessObject o ClienteManager, credo c'è chi preferisce fare in un 
modo chi nell'altro).
Davanti a tutto questo metti un "facade" cioè un oggetto che espone le tue 
funzionalità a chi le vuole utilizzare.
Per quanto riguarda l'interazione col database, ti hanno già suggerito 
hibernate che è un ottimo framework.
Se ti serve qualcosa di piu semplice, puoi usare l'ottimo iBATIS che ti 
consente di estrarre tutto il SQL via dal codice Java, e ottenere DAO molto 
puliti, e continui a lavorare con i tuoi oggetti. Non è così spinto come 
hibernate perchè a differenza di quest'ultimo ibatis non fa il lavoro di 
astrazione della persistenza, nel senso che effettivametne con iBATIS hai 
bisogno dei DAO ancora, soltanto che sono molto puliti e privi di codice 
SQL, tutto il mapping è in un file XML e gestito da IBATIS.
Spero di essere stato chiaro,
ciao

 ciao
Grazie di tutto.

 Grazie di tutto.
Buon Lavoro!

grazie di tutto vedrò di mettere in pratica il tutto e vedo subito di
trovare materiale sui pattern che
a quanto capito sono molto importanti.
