Newsgroup: it.comp.java
Titolo: classi DAO e metodi statici

ho dei Dao che si occupano delle operazioni sul db
in altre applicazioni ho visto che all'interno dei Dao vengono usati
metodi statici
cosa � meglio?
grazie
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


Io nei lavori degli altri ho sempre visto classi normali, mentre io le 
ho sempre fatte tutte statiche (sono partito cos� in php e mi sono 
portato dietro l'abitudine in java). Io francamente non ho mai capito il 
vantaggio di non usare lo statico x un dao e chiedendo a chi aveva fatto 
le applicazioni non mi � mai stata data una risposta accettabile (nel 
senso di sensata), colgo l'occasione anche io per chiedere lumi.
-- 
Z.

 i metodi sono statici non le classi, almeno per quel che ho visto


   i metodi sono statici non le classi, almeno per quel che ho visto
si era un discorso multi linguaggio. In php le classi possono essere 
statiche, in java credo solo i metodi e gli attributi (dato myeclipse mi 
incazza se provo a dichiarare una classe statica). Ma (immagino) che 
logicamente una classe con solo metodi e attributi statici si possa 
considerare statica.
Magari dico cazzate dato sono un niubbone di java cmq :P
-- 
Z.


In genere cerco di evitare metodi statici se non per le classiche 
funzioni tipo trim delle stringhe, funzioni matematiche, cose cos� 
insomma, il perch� � presto detto. Avendo tutti metodi statici prima o 
poi si presentano i classici problemi dovuti al cattivo utilizzo del 
design pattern "Singleton", ad esempio:
- ti rendi conto che non puoi configurare due o pi� connessioni al 
database, o perlomeno richiede molto lavoro. Pensa ad esempio a tutte le 
classi che chiamano i metodi dei tuoi DAO;
- non � possibile avere diverse implementazioni di un certo servizio 
attive contemporaneamente, ad es. per aggregare dati da diverse fonti 
(DB/Web service/Filesystem).
In pratica si ritorna alla programmazione imperativa! Tanto vale 
scrivere in COBOL :) eh eh
Puoi apprezzare l'approccio "normale" come lo chiami tu in tutte quelle 
situazioni che sfruttano la dependency injection, come i vari Spring, 
Guice, Pico Container, ecc.
Certo se l'applicazione � mooooolto ma molto semplice questa gran 
differenza non si nota.
-- 
Dimitri De Franciscis
Phone:  
(+39) 3401570778
Website: 
http://www.megadix.it/

 cosa � meglio?
basta ragionarci sopra: come � possibile che un dao possa fare il suo 
lavoro di dao, cio� astrarre l'accesso dati, se non ha a disposizione 
ereditariet� e polimorfismo?

 ereditariet� e polimorfismo?
ok grazie


 cosa � meglio?
...la mia soluzione per i DAO �...non avere i DAO, ma solo le loro 
interfacce:
http://lambico.googlecode.com
Perdonate la scarsit� di documentazione � un progetto in fase di 
consolidamento. Se siete interessati potete guardare l'esempio nel 
repository degli esempi:
http://code.google.com/p/lambico/source/checkout?repo=examples
e per l'utilizzo, vale praticamente tutto quello che c'era in parancoe 
(e qualcosina in pi�):
http://docs.parancoe.org/reference/html/persistence.html
...se poi qualcuno vuole dare una mano, fatevi avanti!
Ciao
   Lucio
-- 
Lucio Benfante
JUG Padova           
http://www.parancoe.org
 ...have a look at it!
www.jugpadova.it
 
http://www.jugevents.org


Io propendo pi� per dare motivazioni di testabilit� e per consentire 
l'inversion of control.
Francamente polimorfismo nei DAO se ne vede solitamente molto poco, anzi 
rimane sulla carta ma poi l'applicazione finisce per usare sempre la 
stessa implementazione.
Nota per i pignoli: il polimorfismo � effettivamente utile anche per il 
testing...

 interfacce:
con molta franchezza: l'idea di scrivere le query sui nomi dei metodi mi 
lascia perplesso (eufemismo, in realt� mi inorridisce abbastanza).
ma perch� non usare ancora le annotations?
qualcosa del tipo:
@OrderBy("firstName asc, lastName asc")
List<Person> getNomeCheMiPare(
	@Equals("firstName") String firstNameValue,
	@Like("lastName") String lastNameValue,
	@LessThan("birthDate") Date birthDateValue);

 ma perch� non usare ancora le annotations?
Non hai guardato molto la documentazione, vero? :)
Il meccanismo che ti inorridisce � solo uno fra quelli messi a 
disposizione da Lambico/Parancoe. Se fosse l'unico equivarrebbe ad avere 
un query language completo basato sulle signature dei metodi, che 
inorridirebbe abbastanza anche me, se fosse l'unica cosa che posso usare.
Invece l'idea � di avere un meccanismo semplice ed estremamente 
produttivo per introdurre nel DAO le query pi� semplici e comuni, 
eliminando completamente il codice ripetitivo riguardante la gestione 
della sessione, della transazione, dell'esecuzione della query, ecc. 
ecc. Ma lo stesso meccanismo pu� essere, altrettanto semplicemente, 
personalizzato tramite NamedQuery agganciate automaticamente ai metodi 
definiti nell'interfaccia DAO.
Ad esempio, se nel DAO ho il seguente metodo:
@Dao(entity=Person.class)
public interface PersonDao extends GenericDao<Person, Long> {
   List<Person> chiamamiComeTiPare(String conIParametriCheVuoi);
}
E nella classe Person si � definita una NamedQuery corrispondente al 
nome del metodo, con l'interrogazione desiderata, ad esempio:
@Entity
@NamedQueries({
   @NamedQuery(
     name="Person.chiamamiComeTiPare",
     query="from Person p where p.lastName = ?")
})
public class Person {
   // ...
}
Quando verr� invocato il metodo del DAO verr� automaticamente eseguita 
la NamedQuery corrispondente.
Inoltre nel DAO, sono gi� inclusi la maggior parte dei metodi 
generalmente necessari per operare con tale Entity (tipizzati 
correttamente tramite generics), compresi alcuni metodi per gestire la 
paginazione.


 Non hai guardato molto la documentazione, vero? :)
indubbiamente non molto :-) per� vedendolo in prima pagina e ribadito 
come primo esempio nella doc di parancoe mi pareva fosse una key feature.
comunque vedo dai sorgenti l'annotazione @Compare io d'istinto gli avrei 
dato anche il nome della property, magari opzionale. cos� uno coprirebbe 
davvero la quasi totalit� delle query che tipicamente si fanno con un 
approccio orm.
in ogni modo l'approccio aop alternativo all'ereditariet� � molto 
interessante applicato in questo caso. se non fosse che sto smanettando 
su una applicazione google app engine e che accedo al datastore tramite 
jdo lo tirerei dentro al progetto.

 jdo lo tirerei dentro al progetto.
I miei piani nei prossimi mesi sono di introdurre in Lambico il supporto 
ad altri framework di persistenza: io pensavo principalmente a JPA2 e 
iBatis. JDO sono secoli che non lo guardo, se vuoi contribuire, fai un 
fischio.
Ciao
   Lucio


 fischio.
sinceramente molto volentieri. se la mail nome.cognome chiocciola 
gmail.com
 � valida ti contatto l�.
per quanto riguarda jdo diciamo che � un po' resuscitato grazie a 
google. dato che � un hosting java a basso costo imho vale la pena di 
investirci un po' di tempo (e poi mi tornerebbe utile farlo... :-))

 
gmail.com
 � valida ti contatto l�.
s�, � valida.



Se posso chiedere :) ma Parancoe cosa aggiuge allo Spring framework? 
Scorrendo la documentazione velocemente ho solo visto quelle 
interessanti comodit� sui DAO. Aggiunge anche altre feature?


Ciao,
in generale la speranza � di non dover aggiungere niente, nel senso che 
Parancoe � un meta-framework basato principalmente su Hibernate/JPA, 
Spring e Spring MVC. Quindi integra framework diversi per cercare di 
ottenere un ambiente molto produttivo per lo sviluppatore. Le aggiunte 
riguardano solamente parti che non sono fornite adeguatamente da nessun 
framework o libreria esistente, come � avvenuto per i DAO.
Altri pezzi aggiunti sono:
* un sistema di test sul DB che sfrutta i DAO per precaricare nel DB dei 
dati memorizzati in formato YAML (alla Ruby On Rail, per chi conosce 
tale framework)
* un sistema di validazione basato su annotazioni, che si aggancia 
automaticamente ai metodi dei controller (un meccanismo simile � stato 
introdotto in Spring 3.0, quindi nella prossima versione Parancoe 
dismetter� il proprio, per adottare quello di Spring)
* un semplice (ma che nel corso degli anni si � rivelato decisamente 
utile e flessibile) sistema di plugin per le webapp, che permette di 
aggiungere feature alla webapp semplicemente aggiungendo il plugin 
desiderato come dipendenza (o, se non si usa Maven, aggiungendo il jar 
del plugin nella WEB-INF/lib). Ad esempio si pu� aggiungere il 
plugin-security e avere immediatamente autenticazione e autorizzazione 
nella propria applicazione; o si pu� agguingere il plugin-italy e avere 
tutte le entity per comuni/province/regioni con i dati caricati nel DB; 
o ancora aggiungere il plugin-tiles e avere la propria applicazione 
pronta ad utilizzare template tiles invece che le sole JSP.
* un archetype maven che permette di iniziare un progetto in pochi 
istanti, partendo da una webapp in uno stadio gi� sufficientemente 
avanzato (con, ad esempio, gi� l'interfaccia di amministrazione degli 
utenti e ruoli pronta all'uso). Un altro archetype invece produce lo 
scheletro di un plugin di Parancoe, da usare per scrivere i propri plugin.
...mi pare tutto. Ripeto, lo scopo � quello di avere un ambiente di 
sviluppo molto produttivo, in cui non si perda tempo a scrivere 
configurazione, e possibilmente anche poco codice. Ad esempio i DAO 
permettono di eliminarne un sacco, e anche l'utilizzo delle annotazioni 
Spring MVC per i controller. Spesso non si tratta di aggiungere cose, ma 
di spingere ad utilizzare bene le cose che ci sono gi� nell'ottica della 
produttivit�, invece che in quella della flessibilit� (spesso inutile 
quando si scrive un'applicazione e non una libreria).


 dismetterà il proprio, per adottare quello di Spring)
Assomiglia a questo per il mondo JSF?
https://restfaces.dev.java.net/docs-1.3/documentation.html

 
https://restfaces.dev.java.net/docs-1.3/documentation.html
Non mi pare di aver visto supporto alla validazione nel documento a 
quell'indirizzo.
Quello � un meccanismo simile ai controller annotati di Spring, con 
supporto REST (che sar� anche quello suggerito da Parancoe nella 
prossima versione, dato che finalmente � stato aggiunto in Spring 3).
Ciao
   Lucio


 che è supportato da Spring 3.0 stesso.
Ciao,
io intendevo un supporto diretto, nel senso che le feature di Parancoe
(o forse solo lambico?) potrebbero essere implementate come estensioni
CDI oltre che tramite Spring e AOP.
Ora non so bene cosa richieda Spring3, ma con CDI non avresti neppure
un file di configurazione. E poi c'è gente, come il sottoscritto, a
cui non va giù di dover aggiungere Spring alle proprie
dipendenze... :)

 dipendenze... :)
Per Parancoe al momento non ho interesse a farne una versione 
indipendente da Spring, dato che trovo Spring MVC troppo comodo.
Per quanto riguarda Lambico invece s�, e la struttura del progetto � 
pensata apposta per averne implementazioni alternative (Spring, Guice, 
CDI, ecc.). Se sei interessato a contribuire, fatti avanti.


 trover� mai posto in Parancoe.
fratello... :-)
credevo di essere unico ad avere un parere (molto) negativo su jsf e 
quello che ci gravita intorno.

 CDI, ecc.). Se sei interessato a contribuire, fatti avanti.
Si mi interessa, anche per avere l'opportunità di lavorare attivamente
su CDI.  Cosa debbo fare a questo punto?

 quello che ci gravita intorno.
Uhm ma cosa avete contro JSF? ;)  ...ultime versioni intendo.

 su CDI.  Cosa debbo fare a questo punto?
Direi scaricarti i sorgenti, compilarteli e guardare dove puoi 
inserirti. Le idee si possono discutere nella mailing-list sviluppatori, 
quindi iscriviti anche a quella.


 Uhm ma cosa avete contro JSF? ;)  ...ultime versioni intendo.
Troppo complicato per una cosa che dovrebbe essere semplice. Solo per 
maneggiare il ciclo di vita occorre una laurea. Le nuove versioni hanno 
corretto i problemi pi� evidenti (scopiazzando da altri), la 
l'architettura di base rimane, ed � "troppo".
Per me JSF � tecnologia morta. Sopravvive solo perch� fa parte della 
JEE, e solo per questo motivo viene scelta in ambienti molto conservativi.


 JEE, e solo per questo motivo viene scelta in ambienti molto conservativi.
Anche ammesso che sia tecnicamente pessimo, il motivo per cui resiste
sta nel "ecosistema" che gli ruota attorno. Non sto adesso a fare la
lista delle librerie di componenti e framework che gli ruotano
attorno, ma sai anche tu che è piuttosto vasta e di qualità (vedi
Seam) .

 Seam) .
Francamente a me pare che quell'"ecosistema" esista per le carenze di 
JSF stesso. Inoltre quando incontro qualche collega costretto ad usare 
JSF, non lo vedo felice, e questo per me � un indicatore molto importante.


 JSF, non lo vedo felice, e questo per me è un indicatore molto importante.
Forse ha un apprendimento lungo. Io mi trovo bene comunque.
P.S.
L'area sviluppatori è questa?
http://groups.google.com/group/lambico-dev

 
http://groups.google.com/group/lambico-dev
S�


 Uhm ma cosa avete contro JSF? ;)  ...ultime versioni intendo.
personalmente:
la parte view/controller � flessibile come un cristallo di boemia: 
qualunque cosa che esca dallo schema rigorosissimo del loro ciclo di 
vita nella pratica � irrealizzabile. non solo, ma anche il modello "a 
componenti" sul web � molto discutibile e vincola a delle scelte 
sconvenienti, abusa della sessione, costringe a pessime soluzioni per 
ottenere quello che con altri framework mvc si ottiene con eleganza.
per non parlare di ajax, il supporto a4j � impresentabile e qualsiasi 
framework javascript che fa invocazioni remote e/o agisce sul dom � 
praticamente inutilizzabile con jsf.

 praticamente inutilizzabile con jsf.
Mah, puoi usare lo stile di a4j come quello sul DOM: 
http://docs.jboss.com/seam/latest-2/it-IT/html/remoting.html
Perch� poi Richfaces sarebbe impresentabile?

per non parlare di ajax, il supporto a4j � impresentabile 
http://livedemo.exadel.com/richfaces-demo/richfaces/panel.jsf?c=panel&tab=usag
e
questo e' impresentabile ?
peace and love
Nicola
-- 

questo e' impresentabile ?
ahhhh dimenticavo 
sul link che ho postato prima
prova a mettere il theme sakura detto anche japancherry
( sulla navigation --> more --> sakura )
:-)))
Nicola
-- 

 Perch� poi Richfaces sarebbe impresentabile?
per esempio, renderizza i layout come tabelle. cosa che nel web non si 
fa da eoni...

 questo e' impresentabile ?
vuoi paragonare con questo?
http://extui.com/deploy/dev/examples/
ps: sia chiaro non stravedo nemmeno per extjs

 fa da eoni...
I componenti per il layout sono derivati da quelli di yahoo, non mi pare 
usino tabelle...
In definitiva ho capito: JSF � una merda se non usi Seam :). Io lo uso 
quindi non me ne accorgo.

ps: sia chiaro non stravedo nemmeno per extjs
Al di la che a primo occhio ( nn la conoscevo proprio ) extjs mi pare buona.
E anche al di la di un confronto estetico fra le 2 richfaces v extjs, che puo'
pendere da una parte o dall'altra in base al gusto e anche in base a quanto in
futuro cresceranno, mi pare che il punto  focale di un confronto e' che rich
e' una tecnologia molto piu' java/jsf e quindi si gioca piu' a livello di
tag-library e back bean, l'altra mi pare una tecnologia piu' javascript
oriented, piu' alla jQuery ( sempre se ho visto giusto, ci ho dato una
occhiata veloce )
Per sicurezza mia e per lavoro comunque io seguo quandocapita anche jQuery e
il mondo javascript, perche' non si puo' essere troppo sbilanciati su
qualcosa.
In conclusione dire 
"preferisco a livello di presentabilita' rich o viceversa extjs" mi pare una
opinione condivisibile
sparare e dire che "richfaces e il loro supporto ajax sono impresentabili"
mi pare un pochino tifo da stadio poco argomentato e davvero davvero
discutibile. Raccontalo a tutta la community
redhat/jboss/richfaces/icefaces/apache jsf/sun jsf ....
sono ammattiti tutti in un delirio collettivo ? 
Inoltre se io posso scegliere a oggi preferisco stare su java-jsf-tags
piuttosto che su javascript, soprattutto nei progetti b2b dove le "figate"
grafiche non sono indispensabili, e b2c reali ultimamente ne faccio pochi (
l'ultimo era proprio in Vodafone l'autunno scorso e usavo appunto jQuery)
Ciao
Nicola
-- 

 l'ultimo era proprio in Vodafone l'autunno scorso e usavo appunto jQuery)
questa ï¿œ la tua opinione. da notare perï¿œ come, anche nel b2b, queste 
siano sempre meno "figate" (aka frocerie) e sempre piï¿œ requisiti, vedi 
ad esempio le google api (mappe, documents, etc...).

 ad esempio le google api (mappe, documents, etc...).
Credo intendesse applicazioni web  HTML per gli intermediari (esempio
agente assicurativo invece che cliente finale).

 agente assicurativo invece che cliente finale).
beh, io ho visto utilizzate le api di maps in alcune interessanti 
applicazioni dirette all'ottimizzazione dei percorsi di consegna di un 
magazzino. e un cliente ci ha chiesto espressamente l'interfaccia 
evoluta di extjs per il suo applicativo diretto ai soci.

 questo il punto.
Sicuramente, però dicevo che il team di Seam non è quello di JBossAS
quindi non dovresti valutarli in base al loro   application server.
Considera poi che Seam è principalmente di KG il quale davvero non
centra nulla con il JBoss, essendo arrivato dopo ed essendosi sempre
occupato di altro.
Quindi non dovrebbe valere neppure la logica "sempre della stessa
azienda si tratta" in quanto KG tecnicamente fa azienda a se.

 
http://lambico.googlecode.com
Sembra interessante! Come lo integri con spring e Hibernate?
Ciao, Davide.

         @LessThan("birthDate") Date birthDateValue);
Ciao, io sono del parere che le query debbano essere il più finite
possibili, al fine di poterle testare!
Se usi Hibernate o JPA hai i tool che ti consentono di testare una
query, se usi JDBC, hai gli strumenti del tuo DB, per poterci vedere
chiaro. Se però, anche la query HQL la fai scrivere da qualcos'altro,
beh... penso che non ne esci più quando hai un problema!
Sempre tutto molto IMHO!
Anyway, nel 2002 ho fatto una libreria che consentiva di scrivere le
query in file SQL. Per esempio se hai un dao che si chiama ClientiDAO,
avevi le query SelectClienti.sql, SelectCliente.sql,
InsertCliente.sql, etc, nello stesso package della classe che usavi.
Puoi farti un'idea su 
http://code.google.com/p/sqlrepository/
 Il
codice è vecchiotto, ma funziona bene.
Ciao, Davide.


Ciao Davide,
dai un'occhiata a questa mini applicazione di esempio:
http://code.google.com/p/lambico/source/browse/?repo=examples#hg/consoleSpringHibernate
Ciao
   Lucio


On 07/06/2010 10:57, Lucio Benfante wrote:
[cut]
Ciao Lucio, ma interessa ancora il porting per CDI (non ho ricevuto 
risposte nella mailing list)?
Nel frattempo sono andato avanti e ho sul mio HD un inizio di 
implementazione di lambico in CDI. Ora sto aggiungendo il supporto ad 
Hibernate...avrei alcune cose da discutere visto che serve sicuramente 
un refactory dei moduli per rendere le API (l'attuale lambico-core) e 
altre parti il più possibile "framework agnostiche".
Sempre che interessi, altrimenti non vorrei mai che questo porting 
diventi una palla al piede per voi springhisti ;)


Ciao cicap,
certo che interessa. Non ho ricordi di messaggi in mailing-list...ma è 
sicuramente colpa mia. Venerdì dovrei riemergere da un eccesso di 
lavoro, quindi nel week-end mi prenderò un po' di tempo per pensare 
anche a Lambico.
