Newsgroup: it.comp.java
Titolo: Java e DB relazionali


Un buon libro che tratta abbastanza approfondintamente  la materia è stato
scritto lo scorso anno da Blaha e Premerlani, coautori del bestseller di
J.Rumbaugh sull'OO del '91, ed è "Object-Oriented Modeling and Design for
Database Applications". Eccoti il link su amazon:
http://www.amazon.com/exec/obidos/ASIN/0131238299/o/qid=936309767/sr=8-1/002-1639192-0126207
E' anche un buon libro sull'object orientation in generale, dunque ti
interesserà sicuramente (come da tuo thread precedente)
Ugo

 ===== Remov   e "PUNTO" to get my email address.

Io mi sono trovato ad affrontare questi stessi problemi un anno e mezzo
fa, quando ho dovuto creare un interfaccia web per l'accesso ad un
database relazionale.
Tra i requisiti dell'applicazione, si prevedeva che la piattaforma
database dovesse cambiare durante la vita dell'applicazione
[Access(per il prototipo) --> DB2/6000(produzione) -->
DB2/MVS(dimostrativo)].
Devo dire che allora sulla rete circolavano abbastanza infomazioni,
ma poche erano le soluzioni disponibili e pronte all'uso (almeno, per
quanto
ho potuto verificare io).
Tenendo conto che l'applicazione era di dimensioni veramente ridotte, ho
deciso
di affrontare il problema delegando ad una classe server (il business
server) 
la creazione degli oggetti business (cioe' quelli che avevano una
qualche relazione
con le tabelle del database). 
Senza entrare troppo nei dettagli del design, ho utilizzato un pattern
bridge
per realizzare il business server (nel quale, in ultima istanza, e'
stato
confinato tutto l'SQL necessario per interagire con i database). 
Se hai presente il pattern bridge, ho creato:
- una classe Abstraction (concreta) nella quale vengono definiti tutti i
servizi
  necessari per l'accesso ai business objects (selezione, inserimento,
scrittura); 
- una classe Implementor (astratta) alla quale e' delegata la
responsabilità di 
  dichiarare le primitive necessarie all'implementazione dei servizi
definiti 
  dall'Abstraction;
La parte Abstraction del pattern (cioè quella acceduta dalle classi di
interfaccia)
possiede un riferimento alla classe Implementor e ne utilizza le
primitive: essa 
ha un'interfaccia che e' stabile rispetto alle peculiarità della
piattaforma DB
in quanto queste sono incapsulate dalle primitive della classe
Implementor.
Di quest'ultima ne deve esistere un'implementazione concreta per ogni
database verso il quale
si deve fare il porting (e' qui che viene confinato tutto l'SQL
specifico per ogni piattaforma).
In questo modo ho potuto verificare che per portare il database prima da
access verso 
DB2 su AIX e poi verso DB2 su host IBM non si è resa necessaria ne' la
modifica delle
classi di interfaccia (e ci mancherebbe altro!!) ne' la modifica dei
business objects,
nonostante le tabelle e i campi dei diversi database avessero nomi
completamente diversi.
Inoltre, quando ho definito il database su DB2 per AIX, ho anche
definito dei trigger
che si occupavano della generazione delle chiavi primarie. Dovendo
portare il tutto
verso DB2 per MVS (che nella versione allora disponibile non supportava
i trigger), la
responsabilità della generazione delle chiavi primarie è stata
trasferita dal DB al codice
dell'Implementor senza ripercussioni sulle altre classi
Questo approccio si è dimostrato percorribile proprio perchè
l'applicazione
era di piccole dimensioni (8 tabelle di database). In un'applicazione di
dimensioni
maggiori, nelle classi che costituiscono il business server si
accumulano troppi
metodi e diventano molto pesanti da gestire.
Questa e' la mia esperienza.
Attualmente utilizzo ancora VisualAge for Java v1.0 Professional, ma a
giorni mi butterò
sulla v2.0 Enterprise, la quale dovrebbe fornire qualche strumento in
più per la 
realizzazione di applicazioni gestionali (ci crederò quando lo vedrò e
l'avrò provato).
Sono molto interessato allo scambio di idee su questo tema.
Ciao
Roberto
-- 
+---------------------------+
| Roberto Bagnoli           |
| 
robe...@comune.modena.it
 |
+---------------------------+

Roberto Bagnoli wrote:

Anche io. E' un problema molto sentito e spesso viene citato come un campo
in cui l'approccio OO non da consistenti miglioranmenti. Io, a differenza di
te, ho usato un subset di SQL sicuramente compatibile con qualsiasi DB, e ho
spostato su Java features tipo generazione di chiave primaria, ecc. Devo
dire che ha funzionato tutto molto bene (anche perche ancora non abbiamo
cambiato db! ;)
P.S. Su egroups ho anche aperto un newsgroup advanced javaper discutere di
argomenti di questo tipo, ma non so ancora se sia una buona idea. Comunque
se qualcuno nel frattempo vuole iscriversi l'indirizzo è
http://www.egroups.com/group/javaitaly/
.
Ugo

 Ciao,

> database relazionale.
Vi ringrazio per le delucidazioni. Maledizione, ho cominciato a
studiare java e l'oop da poco e ho subito sbattuto il naso contro un
problema affatto banale, da quello che ho letto in giro..
Il fatto e' che mi sembra una questione cruciale per lo sviluppo di
applicazioni complesse in ambito aziendale-gestionale. Se non si
arrivera' a una buona soluzione, magari standard, temo che si
continueranno a scrivere i gestionali ancora per un sacco di tempo con
quei linguggi del cactus (non faccio nomi..) ;-)
Ciao,  
 P.    === Replace "punto" with "." to get my email address.

 quei linguggi del cactus (non faccio nomi..) ;-)
Le soluzioni ci sono, qui si parla solo di soluzioni ottimali per il riuso del
codice, puoi scrivere anche alla maniera del CACTUS come dici tu utilizzando
Java e JDBC. non sei obbligato ad adottare una soluzione OO, che avrebbe tutta
una serie di pregi. Purtroppo però il mapping OO e DB relazionali non è un
problema molto semplice: ma basta usare un DB OO e tutto viene naturale...
basterà aspettare un po' e vedrai che le cose cambieranno, basta vedere la
direzione che ha preso Oracle con la versione 8i, stored procedures in Java e
via dicendo.
Ugo
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Enterprise Java Consulting
@mail: Ugo.L...@Flashnet.it
Home URL: 
http://www.ugolandini.net
Sample Work: 
http://www.sirena.lomb.cgil.it
Work Phone: 02/26254326
Cell Phone: 0347/6310749 - 0347/4783580
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

 via dicendo.
Personalmente non sono molto favorevole alle stored procedure, in quanto
(a mio
parere) introducono un legame troppo stretto tra codice e db, però
l'importante
e' esserne consapevoli e prendere decisioni assennate su quali parti
scrivere come
stored procedure e quali no, in base alle condizioni al contorno che il
problema
impone. Come al solito, non esistono soluzioni buone o cattive in
assoluto, ma solo
relativamente ai problemi che si devono risolvere.
L'argomento e' sicuramente interessante, quindi sarebbe bello sentire i
diversi
pareri in proposito (e tra le altre cose, credo che risollevi un
pochetto il
livello dei temi che ultimamemente sono comparsi nel gruppo)
Ciao a tutti
Buon lavoro


 
http://www.egroups.com/group/javaitaly/
.
Vale lo stesso per me .....
 
http://www.egroups.com/group/javas
potrebbe essere un'idea interfacciare i 2 gruppi!!
Ciao

 Ciao
--


Si, ma almeno ci si puo' provare....
Ciao
GL