Newsgroup: it.comp.java
Titolo: intuizioni

Salve,
dopo avere programmato per diversi anni in java come se fosse visual 
basic 6 e cioè costruendo i miei programmi desktop sull'interfaccia 
grafica, ieri ho avuto un'intuizione e ho capito che quest'approccio è 
sbagliato,infatti se il programma che io realizzo come applicazione 
desktop volessi renderlo disponibile per il web o per i cellulari di 
nuova generazione dovrei riscriverlo daccapo perchè la logica 
applicativa è inclusa nell'interfaccia grafica per cui secondo me 
bisogna separare le classi della Gui dalle classi che implementano la 
logica applicativa in modo che tali classi possano essere riutilizzate 
quando si cambia l'interfaccia grafica.Inoltre le classi che 
implementano l'accesso al database devono essere indipndenti dal 
database in modo da cambiare database facilmente.
Sono corrette queste intuizioni?Se sì che cosa mi consigliate di leggere 
in proposito?
Saluti

 sbagliato,
ora, chiamarla "intuizione" non è proprio un termine azzeccato visto che 
è un argomento ben dibattuto da tempo.
non è che ci siano dei testi di riferimento su come organizzare la 
separazione fra livelli. la regola generale quando vuoi tenere separato 
un livello dall'altro è evitare che ci siano dipendenze circolari, il 
livello più alto può dipendere da quello più basso ma non viceversa. nel 
tuo caso devi fare in modo che i business objects non abbiano 
riferimenti a classi della parte view.
se ti fai aiutare da application framework come spring la cosa ti viene 
del tutto naturale.
-- 
++ Fino all'anno scorso avevo un solo difetto. Ero presuntuoso.
http://unopuntozero.wordpress.com/
http://www.flickr.com/photos/marko_po/

 del tutto naturale.
Ciao e grazie della risposta.Ho scaricato la documentazione in inglese 
di spring.Si tratta di circa 600 pagine che non ho intenzione di leggere 
perchè non ho tempo.Proverò a implementare la cosa utilizzando 
semplicemente Java.
Saluti


Ma, scusa, pretendere di leggersi tutte e 600 le pagine *prima* di
inizare a capire come funziona una tecnologia... beh è come leggersi
prima tutto il dizionario di Russo e poi cercare di parlare!!
Io prenderei il consiglio di rootkit alla lettera: "se ti fai aiutare"
vuol dire, appunto, che i concetti fondamentali stanno altrove, e che
ci sono delle tecnologie che "ti obbligano" a partire subito col piede
giusto.
Inizia a fare un bel refactoring delle tue applicazioni GUI senza
usare un IDE visuale, vedrai che concetti come riusabilità, modularità
ed eliminazione delle dipendenze circolari usciranno da sè. Garantito
al limone
Ciao
--
www.megadix.it

 Saluti
Ti consiglio di dare uno sguardo al pattern Subject/Observer. Ti permette di 
rendere
la 'logica' separata dalla 'grafica'. Potrai fare tutte le modifiche che 
vuoi alla classe
che implementa la GUI senza toccare la parte restante. ;-)
KB

 Saluti
-- 
Andrea Francia
http://andreafrancia.blogspot.com/2008/07/colinux-linux-dentro-windows.html

gian ha scritto:

Pattern MVC
(Model View Controller)
La strada per non avere grattacapi :D
P.S.
A me piace molto il termine "incapsulare il codice" :D

 database in modo da cambiare database facilmente.
Questa cosa, se fatta come si deve, implica non hardcodare il codice SQL
(che, se non è banale, è diverso da database a database)
nell'applicazione ma usare le stored procedures, IMHO.
FJ


Il linguaggio delle stored procedures è diverso da database a database e 
alcuni database non le supportano!! Usare le stored procedure non è 
certo la strada per poter cambiare database facilmente.
-- 
Andrea Francia
http://www.andreafrancia.it/

 certo la strada per poter cambiare database facilmente.
Infatti, le stored procedures devono essere scritte nel linguaggio
nativo del DBMS.
In questo modo, lato Java, si può usare la classica "{call ...}" che è
(questa sì) database-indipendente.
L'indipendenza dal database ha senso soltanto se si vuole installare
l'applicazione in contesti dove esiste già un RDBMS aziendale e il
cliente chiede di usare quello. Un "vero" RDBMS *deve* supportare le
stored procedures. L'alternativa, meno costosa, è scegliere un database
di riferimento e distribuirlo insieme all'applicazione.
Il tutto ovviamente IMVHO.
FJ



no. puoi seguire fondamentalmente due strade:
- usare jpa che ti astrae da sql e database (tipo hibernate)
- avere un livello di astrazione dei dao e creare una implementazione per 
ogni database
legarsi alle stored procedure di sicuro ti salda ancor di più al dbms.


 legarsi alle stored procedure di sicuro ti salda ancor di più al dbms.
Non vedo una grossa differenza tra creare uno strato database-dipendente
in Java e crearlo nel linguaggio nativo del DBMS, se non che la seconda
strada è solitamente più efficiente e in alcuni DBMS può avere anche
altri simpatici vantaggi (es. check degli errori a compile time anzichè
a runtime).
FJ

 stored procedures. 
Magari a volte le stored procedures non servono ed è sufficiente un db 
non "vero".


 a runtime).
Spostare tutto dentro il DBMS renderebbe le cose piu' difficili da
modificare e mantenere. Un fattore non da poco.
Credo che usando (generalemente) JPA si risolvono questi e molti altri
problemi. Poi dipende dall'applicazione, certo.


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

 Hai mai tradotto una SP da Oracle a Microsoft o viceversa ?
Allora, provo a riassumere il mio pensiero per l'ultima volta perchè
vedo che non ci capiamo proprio:
1. fare un'applicazione che funzioni (e scali correttamente) su diversi
database ha un costo superiore rispetto a scegliere un DB di riferimento
 e supportare solo quello, quindi si fa solo se esiste una richiesta in
questo senso.
2. lo so anch'io che il linguaggio delle SP è proprietario del vendor,
ma il punto non è questo. Il punto è che, per fare un'applicazione
scalabile, anche le tecniche sono diverse. Sì, ho tradotto SP da
Microsoft a Oracle, ma il problema non è tanto il linguaggio procedurale
diverso (che si impara, eh, non è come tradurre dal basco al cinese)
quanto il modo stesso di fare le cose. Per dire, ho visto che i
programmatori SQL Server spezzano una query complessa in tre o in
quattro query semplici creando tables temporanee on the fly, questo in
Oracle non si fa e si cerca di fare stare tutto nello stesso statement
invece.
3. poi se mi dite che JPA è la soluzione a tutto e che un'applicazione
scritta in JPA scala allo stesso modo su 5, 500 o 5 milioni di righe su
qualsiasi database, da MySQL a Oracle, bene, allora vuol dire che la
soluzione giusta è quella e non la mia. Io ho solo riportato la mia
opinione maturata in base all'esperienza, mia e di altri.
FJ