Newsgroup: it.comp.java
Titolo: semplici domande su Pattern DAO

Salve a tutti.
 
Sto sviluppando un semplice gestionale in java con annesso DB mysql. Nonostante non ci sia alcun pericolo di cambiare questo tipo di accesso ai dati, ho scelto di  implementare il pattern DAO.
 
Mi sono informato su di esso, ma non riesco ad afferrare un paio di punti (sono un novizio programmatore).
 
Come da manuale ho implementato
  classe cliente (coi vari metodi set e get)
  classe clienteDAO (con i metodi CRUD: create, read, update, delete)
 
  classe pratica (come sopra)
  classe praticaDAO (come sopra)
 
 
Espongo dunque il primo dubbio, che mi viene quando vado ad aggiungere altre feature, come il metodo
  getPraticheDelCliente()
 
dove suggerite di scrivere tale metodo? in clienteDAO o praticheDAO?
Potrei farlo facilmente in entrambe le classi, ma visto che di questi metodi ce ne saranno parecchi, vorrei impostare il lavoro in maniera corretta fin da subito.
 
Vi ringrazio fin da ora per un qualsiasi consiglio.


Non so dirti in letteratura se la cosa sia affrontata in modo diverso, 
ma io da sempre metto nel suo DAO cio che mi restituisce l'oggetto (o 
una collezione di oggetti) del suo tipo.
Mi spiego meglio:
getPraticheDelCliente() restituisce una collezione di pratiche, quindi x 
me � senza dubbio un metodo del DAO praticaDAO.
 
-- 
Z.

Grazie per la risposta. Penso che farò anche io così.
 
Altro dubbio: è normale che poi una classe DAO (praticheDAO, per continuare l'esempio), si riempia di decine di metodi, oltre ai già citati CRUD?
Dovrò implementare robe come
  getUltimaPratica()
  getPratichePagate()
  getPraticheSospese()
  ..
e chi più ne ha più ne metta.
Come è meglio procedere? Non mi preoccupo e vado avanti, oppure è meglio organizzarsi con qualche sistema alternativo?
 
Grazie ancora!

 Come ï¿œ meglio procedere? Non mi preoccupo e vado avanti, oppure ï¿œ meglio
organizzarsi con qualche sistema alternativo?
CUT
 
mah, non credo che esista un limite consigliato al numero di metodi da
implementare in una classe, cioï¿œ ognuno si regola come risulta necessario
dallo sviluppo software nel caso specifico. Questo anche in considerazione
del fatto che esistono alcune API di alcune librerie Java che
possono avere anche molti metodi, ma questo non inficia affatto l'usabilitï¿œ
della libreria stessa, dato che di solito i metodi che vengono usati sono una
parte. Quindi puoi stare tranquillo ed implementare nella tua classe
tutti i metodi che ti servono.
 

 Potrei farlo facilmente in entrambe le classi, 
 
ecco questa sarebbe una cazzata. se devi duplicare codice è inutile ti 
metti a ingegnerizzare, puoi scrivere le query direttamente negli oggetti 
business dove ti servono...

 citati CRUD?
 
ovviamente sì.
 
ps: prova a dare un occhiata a questo progetto: 
http://projects.spring.io/spring-data/
 

 Grazie ancora!
 
Oppure fai una getPratica(argomento) dove come argomento avrai
ULTIMA|PAGATE|SOSPESE|ecc.
Direi che dipende da quanto codice hanno in comune i metodi.
Oppure una via di mezzo: verso l'esterno tieni dei metodi wrapper
getUltimaPratica(), getPratichePagate() ecc. che poi chiameranno un
metodo generale privato getPratica(argomento).
 
Ciao Jack
-- 
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

Ringrazio tutti per i preziosissimi consigli. Non ci speravo davvero.
 
Tra poco posterò altri dubbi sul DAO :)

Riguardo a COME accedere alla classe DAO, avrei pensato ad una strategia:
 
classe ClienteDAO come 'nested class' pubblica e statica nella classe Cliente
 
STATICA perchè può non riferirsi a nessun istanza in particolare. Es.:
  lista = ClienteDao.getClientiPeggiori();
 
PUBBLICA perchè devo accedervi da ovunque.
 
'NESTED' così posso rendere privati alcuni metodi "critici" di Cliente. Es.:
  private void setSaldoCliente() {}
In questo modo solo ClienteDAO e Cliente possono maneggiare il saldo. Se ClienteDAO fosse una classe top-level, dovrei rendere il suddetto metodo public, col rischio che tutto il package possa usarlo (tutta l'applicazione è in un unico package).
 
 
Secondo voi queste sono scelte scellerate? Spero di non aver detto eresie. Ricordo che sto muovendo i primi passi in java :P
 
Ringrazio.

 l'applicazione è in un unico package).
 
questo sinceramente mi lascia perplesso. ovvero, il concetto di "private" 
nella programmazione a oggetti è legato a questioni di design, non di 
sicurezza del dato. ricordati che tramite reflection si può 
tranquillamente aggirare i vincoli dei modificatori, per cui se ritieni 
sia un "rischio" che il resto dell'applicazione lo possa invocare allora 
vuol dire che c'è qualcosa che non va nell'approccio. la sicurezza del 
dato non si ottiene mettendo "private" alle proprietà che vuoi rendere 
sicure.
 
a mio modo di vedere la classe Cliente è una entity che mappa il 
database, ovvero un pojo con le sue proprietà, mentre ClienteDAO è il dao 
e sta nel suo package dei dao.

 e sta nel suo package dei dao.
 
Quindi suggerisci una divisione del progetto in più package? Uno per le classi di dominio e uno per le classi DAO?

 classi di dominio e uno per le classi DAO?
 
eh beh, se fra un mese ci vuoi capire ancora qualcosa... :)

Ok ho capito. Stanno venendo fuori tutte le mie lacune riguardo questo paradigma di programmazione :P
 
Ora cerco di elaborare meglio tutta la faccenda.
 
Per il momento grazie.

Ok. Con una migliore divisione delle classi risolvo le questioni inerenti al DOVE piazzare le classi DAO. Ora stanno nel loro bel package, ben separate dai package della business logic e quindi per forza di cose pubbliche (credo :D ).
 
Uno dei dubbi che mi resta è però presto detto.
 
ClienteDAO ha ovviamente
  import business.Cliente
  ...
 
Ma la classe Cliente è giusto che abbia
  import dao.ClienteDao ?
 
Con questa domanda sugli import arrivo ad un problema più profondo:
 
ClienteDao ha ad esempio il metodo
  void update(Cliente c) {}
 
E' scellerato implementare un metodo update() anche in Cliente, in modo da istanziare ClienteDao e gestire per esempio le eventuali eccezioni generate durante l'update dell'oggetto?
 
Se faccio così, in Cliente devo importare dao.ClienteDao..
 
 
 

 generate durante l'update dell'oggetto?
 
no, non va bene. 

Ok.
 
In giro per la rete ho visto anche la soluzione di inserire nella classe Cliente l'attributo
  private ClienteDao dao;
e quindi accedere ai dati nel seguente modo:
  Cliente titolare = new Cliente(42);
  titolare.dao.read();
 
Sapreste indicarmi i vantaggi o gli svantaggi?
 
Grazie


Dipende, in alcuni casi ho utolizzato un filtro con un metodo unico, ad 
esempio listPratiche(FiltroPratiche filtro), dove FiltroPratiche e' il 
luogo del contratto tra chi chiama ed il chiamato.


Spaghetti o non spaghetti?
 
A mio avviso la classe Cliente e' un semplice bean con le propriet� del 
cliente. Eventualmente la Pratica, tra le sue proprieta', potra' averne 
una di tipo Cliente.
Comunque. far conoscere al modello dati chi e' il suo controller, mi 
sembra che non sia MVC, e che si deleghi al modello responsabilita' che 
non sono sue.
 

Grazie per le risposte.
 
Attualmente sto lavorando con la classe Cliente semplice bean, come suggerito più volte, e le classi DAO con solo metodi statici e costruttore nascosto (private vuoto).
 
Non uso alcuna interfaccia tra Cliente e ClienteDAO.
 
E' da giorni che giro per la rete, col risultato che i dubbi aumentano mentre le poche certezze restano costanti :)
Però vado avanti!