Newsgroup: it.comp.java
Titolo: Data access object

Ciao
Ho una domanda che mi pongo ogni volta che leggo dei tutorial ed
esempi su java per quanto riguarda applicazioni che utilizzano basi di
dati.
Per esempio supponiamo di dover realizzare la classica web application
per gestire ordini e prodotti in un database quindi le classi di
dominio saranno Product, Order, OrderDetail etc..
Prendiamo la classe Product ad esempio ora devo realizzare le classi
con cui andrò a reperire i dati dal database quindi in base a molti
tutorial utilizzando i data access object (DAO) ci dovrebbero essere
le seguenti classi:
IProductDAO, l'interfaccia con i metodi che dovrà implementare poi la
classe concreta ProductDAO per prendere i dati.Fin qui ok ho capito ma
non capisco perchè oltre a questi DAO ci sono anche l'interfaccia
IProductService o IProductManager e la classe concreta ProductManager
o ProductService che confrontandole con le classi DAO hanno gli stessi
metodi solo che la differenza sta solo che nel DAO concreto non
gestisco per esempio eccezioni ed errori cosa che avviene invece nella
classe manager o service concreta..
Quello che mi chiedo è se per forza devo avere da una parte classi DAO
e in più anche classi simili manager o service chiamiamole come
vogliamo, non posso avere solo un interfaccia più  la classe concreta
che la implementerà e poi gestire errori che ne so da una altra parte
nel controller? Spero di aver scritto bene la domanda e scusate le
ripetizioni di parole.
Grazie a chi mi chiarirà questo dubbio..ovviamente sono alle prime
armi con java e le architetture ancora non capisco certe cose per
questo ho chiesto.
Ciao

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

 manager o service concreta..
nei casi "semplici" che hai visto questo disaccoppiamento fra il dao e il 
manager può sembrare un inutile overhead, e in effetti i tutorial non 
sono esaustivi. in realtà la vera forza di questo disaccoppiamento sta 
nel fatto che i manager possono essere transazionali (e di solito lo 
sono) e ciascun loro metodo può eseguire più operazioni dao, anche su dao 
diversi, aggregandoli in una transazione. i metodi del dao per loro 
natura e utilità dovrebbero essere quanto più possibile "atomici" e non 
dovrebbero avere alcun riferimento alla gestione della transazione 
(commit o rollback).

 Andava di moda anni fa creare dei pattern noiosi e fastidiosi.
moda?
immagino che parti dall'assunto che in tutto il mondo java si utilizzi 
jpa e gli ejb 3. non è così. nel j2ee c'è già un disaccoppiamento e hai 
già chi ti gestisce le transazioni, ma hai mai pensato come faresti fuori 
dal j2ee?
 

 dal j2ee?
Si verissimo.
In effetti nei progetti senza ejb1/2/3 il manager e' necessario proprio alla
transaction.
Complimenti, sempre preciso
ciauz


Bene adesso ho capito meglio questo concetto
Se quindi snon dovessi usare il data access object e creo direttamente
delle classi manager dove eseguo direttamente operazioni sul database
e query, gestisco transazioni ed errori  va bene lo stesso o è meglio
fare sempre questo disaccoppiamento per una buona architettura dell'
applicazione?
Grazie in anticipo
Ciao



per andar bene va bene tutto... il problema è che se hai dieci 
transazioni che fanno tutte un insert/select/update sulla stessa tabella 
quell'istruzione sql la riscrivi dieci volte.


Infatti. Mentre le query sono di fatto logica di business e quindi non c'e'
nulla di male a sparpagliarle in giro nei metodi funzionali, anzi e' imho
consigliato, la gestione della transaction (CHE E' OBBLIGATORIA) e' una
seccatura ripetitiva, noiosa e va centralizzata per forza oltretutto per
evitare per evitare di sbagliare e introdurre bug
Anche la gestione connections va comunque centralizzata
QUindi per riassumere.
1. (
Usa degli Ejb ( qualsiasi 1/2/3 ) che ti danno la transaction completamente
gratis e
centralizza solo le connection e le query nei DAO
2.
Usa Ejb3 che ti danno connections e transaction gratis sparpaglia le query
dove vuoi
2.
Se non usi gli ejb fai dei DaoService che estendonono una classe DaoBase che
gestisce connessioni e chiusure.
Poi fai i manager per la transaction
Forse si puo' anche "cacciare" la transaction nel service e abolire i
manager, ma non ho voglia di pensarci perche' sto cucinando :)
Se proprio li odi sti manager ci pensiamo tutti un po' su e vediamo come
"farli fuori" comunque :))
Ciao


Devo aver risposto a qualcuno in privato cliccando per sbaglio
rispondi all'autore mi sembrava di aver risposto qua invece non trovo
la mia ultima risposta
Comunque vi ringrazio adesso ho capito molto meglio il perchè di
questi disaccoppiamenti!
Ciao