Newsgroup: it.comp.java
Titolo: POJO, DAO, Service ...

salve a tutti...
sto imparando Hibernate ma faccio un po di casino...
non ho capito bene i "compiti" di ognuno dei 3 elementi...
- pojo
- dao
- service
Service sembra essere una specie di contenitore di metodi di comodo... tipo:
getTuttiGliOrdiniOrdinatiPerData()
getOrdiniUrgenti()
ecc...
ma in fondo per fare queste query ci vorrà cmq una query appoasita anche nel
dao o nel pojo e quindi service a che serve??
(tra l'altro mi sembra di tornare agli inizi (della mia esperienza in java)
quando avevo messo tutte le query in una classe statica
e lanciavo man mano cio che mi serviva (ma almeno il codice SQL era tutto in
un posto)... ma è davvero questo il senso dei 3 elementi sopra???
ciao e grazie


Eh, già, per semplici operazioni CRUD (Create-Read-Update-Delete) c'è
una forte duplicazione del codice (aggirabile facilmente con qualche
accorgimento), però i vantaggi sono molti e non sempre apprezzabili al
primo "giro".
--
www.megadix.it

 ciao e grazie
non c'e' de che
ciauz Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 l'architettura pura che ti ho accennato )
quindi tu introduci ancora un'altro strato tra pojo (javabeans) e i dati che
usi nella app?
ancora un altro *travaso* ?? ;-)
sto facendo tutte queste domande su struts/hibernate proprio perchè sto
cercando di capire: ma è
mai possibile che i campi che uso nel DB li debba spalmare ovunque?
Se scrivo il database (e già parto male perchè con hibernate mi risulta
dovrei iniziare con la specifica del dominio dei dati a oggetti)
mi ritrovo a:
- specificare i campi nel DDL
- specificare i campi nel DAO (per fare la query opportuna)
- specificare i campi nel POJO
- specificare i campi nella ActionForm di Struts
e tu aggiungi anche un altro livello!!?!?!? aiuuuuuuuuuuto!
Scherzi a parte il mio dilemma è questo. Ma non si riesce a scrivere i POJO
e poi tutto il resto si automatizza?
Sto sognando o ancora non ho capito come fare a ottenere ciò che voglio?
Nella mia mente l'idea è: una volta scritto un POJO devo fare
MioPjo load(int pk)  e  save(istanzapojo) ..... stop (ovvio che parlo per le
app semplici, poi quando ci sono JOIN e strutture dati più complesse allora
è un altro discorso...)
Forse ho fatto dei discorsi un po' annodati... spero capiate...  grazie
ancora

 ancora
Si purtroppo e' cosi'. L'architettura applicata in modo rigoroso di un
progetto struts-hibernate e' sovraingegnerizzata in modo evidente e richiede
parecchi travasi che fanno innervosire parecchio.
E' proprio per quello che nel post precedente ti suggerivo per lo meno di
elimineare quello che tu chiami il livello service, volendo volendo potresti
eliminare anche i DAO e inpratica negli action potresti tenere tutta la
logica e anche il data layer e quindi manipoli i pojo nell'action diretto.
Vedi te incasini un po' la leggibilita' ma non muore nessuno.
Proprio per fare fronte a questa inequivocabile sovraingegnerizzazione che
hai notato sono stati scritti gli ejb3 che possono essere usati direttamente
nelle jsf ad esempio andando a eliminare i formbean, gli action bean, i
session bean ( qullo che chiami service ) e anceh i DAO
In futuro struts-hibernate verra' soppiantato da jsf-ejb3 che e' 1000 volte
piu' semplificato proprio perche' abolisci in tronco tutti questi layer,
questo e' la direzione in sun. Esiste anche un frameork , jboss seam, che
appunto unisce in modo integratissimo jsf+ejb3 ( e fa molto altro )
Al momento comunque la stragrande maggioranza dei progetti attivi enterprise
sono struts-hibernate quindi se sei in un progetto cosi' o volessi iniziarne
uno oggi cosi' va benissimo, ci abbiamo lavorato per anni in
struts-hibernate e siamo ancora vivi e i progetti cammminano benone,
perderai un po' di tempo con qualche travaso ma poi ci si abitua e ci si
velocizza mano a mano che lavori.
ciao e buon lavoro


 velocizza mano a mano che lavori.
i miei per ora sono solo struts come progetti e visto che devo partire con
uno nuovo mi piacerebbe almeno integrare hibernate
(volevo passare a Spring+Hibernate, ma onestamente dopo aver letto qualche
libro mi sembra giŕ abbastanza difficile partire con la sola persistenza)
Che dite altrimenti mi fondo il cervello e parto di Seam??? (ma Seam funge
solo con JBOSS???)
grazie a tutti


Eh, no caro, sono discorsi serissimi e...purtroppo antichi. Già perché
gli sviluppatori (noi tutti compresi) si sono un po' stufati di
ripetersi continuamente. Alcune soluzioni alternative ci sono:
- Naked Objects: 
http://www.nakedobjects.org/home/index.shtml
 che fra l'altro utilizza Hibernate come Object Store di default;
- Ruby On Rails e amichetti vari anche fuori dalla sfera Ruby, come
Grails, PHPCake, ecc. Anche qui Hibernate "spadruneggia" :)
In realtà con Hibernate e spring MVC un paio di "travasi" li puoi
evitare tranquillamente:
- scrivi prima i mapping e le classi, e lasci che sia hbm2ddl a
generare i DDL;
- con Spring MVC non c'è bisogno di utilizzare classi XXXForm, puoi
utilizzare tranquillamente i tuoi oggetti "POJO".
Ho sperimentato sia Naked Objects che Ruby on Rails che CakePHP e
altri, ma non mi sono impressionato più di tanto, ecco perché:
- Naked Object: va bene per fare dei prototipi, ma mettere mano alle
interfacce utente auto-generate è un delirio;
- Rails e amici: si basano tutto su linguaggi di scripting (già questo
basterebbe a mollarli) e un sacco di convenzioni e "magie" date per
scontate, roba che se fai mezza cosa in modo diverso devi perdere un
sacco di tempo dietro al voodoo.
Ti consiglio comunque di dare un'occhiata a queste tecnologie, magari
a te fanno comodo...
--
www.megadix.it

 grazie a tutti
de nada
ciauz Nicola



Se usi Hibernate devi specificare solo i pojo. In piu' hai le actionform se 
usi Struts (non se usi JSF o qualche altro moderno framework).
Quindi se ti appoggi a framework recenti (per il web e per la persitenza) 
hai una sola definizione degli attributi dei tuoi oggetti da fare, e volendo 
la stessa definizione definisce anche il DDL (qualche tool di hibernate 
genera lo schema a partire dai pojo annotati o configurati in xml).
Se usi sia lo strato DAO che service assieme a Hibernate puoi avere qualche 
ridondanza (non e' un grosso problema pero' secondo me):
public class UserDao {
  ...
  public User getUserById(Long  id) {
    return hibernateSession.load(id, ...);
  }
}
public class UserService {
  @Transactional
  public User getUserByID(Long id) {
    return userDao.getUserById(id);
  }
}
Come vedi il service non e' che abbia aggiunto molto di piu' se non 
un'annotazione per la gestione della transazione (e' un'annotazione di 
Spring). In altri casi invece puoi integrare tra loro i risultati ottneuti 
da piu' chiamate ai dai e allora si rilevano molto utili. 

 wrote:

Eh, no caro, sono discorsi serissimi e...purtroppo antichi. Già perché
