Newsgroup: it.comp.java
Titolo: client "fat" e non...

devo realizzare un software gestionale che fornisca i dati contenuti in un
db sia a client di tipo "fat" (cioe' un'applicazione scritta con le swing)
sia
a client leggeri (cioe' web browser). si dovra' usare j2ee (oracle ias)
non vorrei duplicare inutilmente il codice di presentazione dei dati, e mi
chiedevo se qualcuno aveva gia' affrontato un problema simile.
grazie.

 non vorrei duplicare inutilmente il codice di presentazione dei dati, e mi
Se non vuoi duplicare il codice hai una sola strada: ficcare tutto dentro
al database con stored procedure a go go.
Davide

 al database con stored procedure a go go.
E come risultato l'applicazione non sarà portabile verso altri database.

 E come risultato l'applicazione non sar portabile verso altri database.
Lui ha specificato che "si dovra' usare oracle", quindi la
portabilita' verso altri database non mi sembra un problema.
Poi, la portabilita' da un database ad un'altro e' una chimera: o usi
solo SQL "standard", e ti giochi il 98% delle capacita' di un database
"intelligente" per poter usare anche un database lobotomizzato,
ed anche qui' hai i tuoi problemi: pensa solo alla differenza di
gestione di ID autoincrementanti tra Oracle e SQL Server,  oppure
decidi di limitare la portabilita' verso altri database ed usi Stored
Procedure et similia.
Davide

IMHO, è il classico contesto in cui deve essere applicato MVC.
Sarebbe opportuno avere un'application server in cui deployare dei bean che
incapsulano la logica business e di accesso ai dati. Pensi di utilizzare un
EJB server? Secondo me potrebbe essere ottimamente applicabile al tuo caso.
Lo strato di presentazione può così interagire con i servizi esposti
dall'application server che è quindi unico sia per un rich client (swing)
che per JSP o altro. Potresti in un momento successivo pensare di inserire
uno strato per trasformare i servizi offerti dall'application server in web
services, in modo che applicazioni non java possano poi sfruttarne i
servizi.
Al database gli farei fare soltanto il database, oltre che per non
introdurre dipendenze, anche perché non è molto corretto che lo strato che
contiene i dati si occupi poi anche e soprattutto di maneggiarli.

> Poi, la portabilita' da un database ad un'altro e' una chimera: o usi
Ti garantisco che non sempre è così, molte chimere sono meno chimere quando
funzionano. Inoltre non sempre devi scrivere una query per tirar fuori dati
dal db, anche se spesso è così.
Salvo quando non espressamente richiesto (sigh!) cerco di fare in modo che
le query siano ANSI SQL92, che già mette a disposizione un set di istruzioni
che offre la maggior parte delle operazioni necessarie, e che funziona sulla
maggior parte degli rdbms. Quando uso qualcosa di specifico cerco di
isolarlo in un componente separato, il che spesso si traduce in overwork di
sviluppo che il "richiedente" di cui sopra non comprende (ma se ogniuno fa
il suo lavoro e gli aspetti tecnici li decide chi sviluppa, questo non
dovrebbe mai capitare).
Non sono un'amante delle stored procedures allo stesso modo in cui non amo i
javascript; la logica mi piace che rimanga nel business tier, e non sullo
strato di presentazione o in quello dei dati.

 contiene i dati si occupi poi anche e soprattutto di maneggiarli.
Però, quando un programma che usa JDBC ci mette 1 minuto a fare quello che con
una stored procedure ci mette 5 secondi... insomma, lo si può anche prendere in
considerazione.
Ciao,
 Stefano
----------
"X WindowSSS, teSSSoro mio... lo odieremo per SSSempre"
Bill Gollum
----------

 introdurre dipendenze, anche perché non č molto corretto che lo strato che


Premetto che credo che tutte le cose dette sin qui hanno dal punto di vista
di chi le ha scritte una pura e sana verità.
Tuttavia per il discorso delle stored procedure io avrei qualcosa da dire:
non è vero che quello che si fa in un minuto in java vien fatto in 5 secondi
con le stored procedure visto che in questi mesi mi son occupato di
statistiche su moli di dati dell'ordine del milione e mezzo di record e ho
provato le due vie ed alla fine ho visto che se ben programmate con tecniche
di tuning si hanno praticamente gli stessi tempi sia con Oracle che con
Enterprise Server di Sybase.
Inoltre io eviterei il gestionale allacciato agli EJB visto che (sempre a
mio avviso) risulterebbe davvero pesante.
Buon lavoro e ricordate che è soltato la mia opinione :)
--
--------------------------------
Andrea Musumeci
java programmer free lance
work:           
www.javalab.it
fun&friends: 
www.fauser.it/olimpo76
--------------------------------

 idee?
Dato che devi ancora scegliere, io ti consiglio di usare Personal Oracle,
e poi di fare la sincronizzazione usando gli strumenti di Oracle stesso.
NOTA: mi sono trovato a fare qualche cosa di simile ed e' stato un
bagno di sangue... e il sangue era il mio...
Davide

Sugli aspetti di stored procedures, sono d'accordo; anche se non ho mai
fatto dei test per verificarne le performances.
Per quanto ho visto finora, mi sembra che la pesantezza degli EJB si
accentui quando si fa un cattivo uso di entitybeans. Evitando i finder,
facendo un appropriato uso di value object e session bean che coordinano il
workflow, penso che la pesantezza possa diventare trascurabile. Voi cosa ne
pensate?

 considerazione.
Parole sante :-). Se una cosa è meglio farla con una stored procedures
perché ci mette 1/10 del tempo che ci vuole con un'altra tecnologia...
allora ben venga. Ma io prenderei questo approccio come eccezione, non come
regola (se mi rendo che una roba è lenta allora comincio a valutare se è il
caso di provare una stored procedure - non viceversa).


Again, se hai astratto correttamente il database, si tratta semplicemente di leggere un
oggetto da A e scriverlo su B. Lo so, sembra minimalista, ma OO e' proprio questo:
semplicita', non complessita'. Chi ti vende la seconda, ti sta fregando :-)
Ciao,
    Bruno.
---
| Bruno Bossola
| A Java Software Engineer :-)
| 
http://digilander.iol.it/bbossola

 wrote in message
news:3cac0292...@news.inet.it...
