Newsgroup: it.comp.java
Titolo: [design][lungo] indipendenza dal database: possibile?

L'idea e' quella di sviluppare un'applicazione "db-based" che sia 
indipendente dal db fisico scelto (requisiti irrinunciabili sono che 
funzioni sia con Oracle che con DB2, ma poi se 2 xche' non "n"?). 
Sicuramente non e' un'idea nuova e qualcuno c'avra' gia' perso tempo 
analizzando i pro e i contro....
Cosa mi consigliate di guardare per iniziare a buttar giu' qualcosa?
L'idea banale che ho avuto e' quella di un "punto d'accesso" al db, una 
classe astratta, che fornisca le operazioni principali specializzate poi 
dalle sottoclassi. Se non dico una stupidaggine: un "Factory Pattern" 
abbastanza semplice, seguendo le orme dell'esempio per i ConnectionPool di 
Ugo Landini sul suo sito. Data una connessione, l'applicazione dovra' 
quindi effettuare una serie di query (identificate da un codice). L'idea 
(che a me non piace troppo) e' quella che l'applicazione fornisca codice 
della query e parametri a questo modulo per l'accesso al db, il quale 
traduce la query in un'interrogazione valida sullo specifico db e 
restituisca i risultati. Scrivere codice sql "portabile" e' stato scartato 
in quanto ci sono differenze nelle varie implementazioni e anche aderendo 
strettamente allo standard non si puo' essere sicuri che funzioni (senza 
contare le limitazioni proprie dei singoli db e le estenzioni proprietarie 
che invece permettono di velocizzare il lavoro e che in questo modo non 
potrebbero essere sfruttate). A me non piace molto poiche' la logica degli 
accessi al db rimane cmq nell'applicazione (anche se le query non sono 
espressamente indicate ma sostituite da un codice) e il tutto non mi sembra 
molto O.O. (d'altra parte l'applicazione e' fortemente "db-based" quindi 
bisogna rimanere anche sul pratico), invece mi piaceva l'idea di poter 
spostare del tutto la logica degli accessi dentro questo "modulo" 
intercambiabile e lasciare lavorare l'applicazione ad un livello piu' alto, 
con degli "oggetti dati" (Bean, principalmente). Probabilmente pero' era 
chiedere troppo (sicuramente il tutto verrebbe piu' complicato, anche per 
gli analisti che non hanno grande esperienza di O.O. e si trovano meglio 
con i diagrammi di flusso).
A questo punto: e' sbagliato seguire un sorta di "strategy pattern" per la 
traduzione delle richieste del client (codice+parametri) in un algoritmo 
concreto (query valida sul db specifico) per le operazioni sui dati?
Quanta "estensibilita'" mi garantisce questo approccio (se valido?).
Basta un "proxy" per dire di essersi "astratti dal db?". Io non ne sono 
troppo sicuro...
Non posso dare ulteriori informazioni poiche' non le ho neanche io (non 
spetta a me l'analisi di questo progetto, ne' ho intenzione/possibilita' di 
farla io per vari motivi, anche se mi e' stato chiesto di fornire 
delle idee) ma spero che quanto scritto sia abbastanza esplicativo del 
problema da risolvere...
Se ho scritto castronerie/baggianate scusatemi, ma vado un po' di fretta :P
Se avete suggerimenti o link da guardare: ve ne sarei grato.
-- 
Ciao,
Matteo

Ciao Matteo,
sarò abbastanza franco con te: credo che tutto quello che hai scritto sia
un insieme di buone idee ma penso di poter dire (e son pronto a
scusarmi se sto sbagliando) che non sia altro che la definizione
di 'driver jdbc'...
Tutte le applicazioni che fino ad oggi ho scritto in 2 or 3 tier non si son
mai appoggiate ad una tipologia specifica di database ma son state scritte
sfruttando le interfaccie dei driver jdbc e poi registrando nello specifico
a runtime la classe nel driver manager piu' adatta all'occasione...
Sembra che nello specifico il tuo problema sia quello di dover scriver
query che giran su tutti i db; io penso che sia semplicemente risolvibile
sfruttando soltanto lo standard sql Ansi92 ed evitando costrutti proprietari
per i quali (se proprio necessari) opterei per delle storedprocedures che 
prendon in ingresso sempre gli stessi input e danno gli stessi output e che
vengono implementate a seconda dei casi lato server db.
A questo punto inizio anch'io a scusarmi se esiste una via alternativa
di interpretazione a quello che volevi dire.
**************************************************
         Andrea Musumeci
   java programmer freelance
 
www.javalab.it
 
www.fauser.it/olimpo76
**************************************************

 
no anzi, l'interpretazione giuesta era quella. mi rendo conto che e` una
domanda che puo` sembrare stupida, pero` in definitiva e` proprio
questa:
sei io scrivo codice ANSI sql92, e lo testo ad esempio su oracle, sono
sicuro che cambiando semplicemente driver l'applicazione va
tranquillamente con un altro db? Con "qualsiasi" altro db? A qualsiasi
livello di complessita` del codice sql? Senza toccare una riga di quel
codice sql?
Vorrei che qualcuno mi rispondesse "SI" xche` x me sarebbe molto comodo
togliermi subito questo "pensiero" ...il fatto e` che io con le
conoscenze che ho non posso confermarlo ne` smentirlo (per quanto ho
fatto fin'ora bastava, appunto, cambiare driver jdbc e tutto continuava
+/- a funzionare! ;)
-- 
Ciao,  |     Gott weiss ich will kein Engel sein
Matteo |                     -- Rammstein, Engel

 tranquillamente con un altro db? Con "qualsiasi" altro db?
vorrei solo precisare che ovviamente il "qualsiasi" e` virgolettato in
quanto il dbms si pressupone cmq essere "di fascia alta".


+/- a funzionare! ;)
Diciamo che se hai mai avuto esperienza di porting "tradizionale", la
combinazione Java/JDBC assomiglia molto, in generale, ad un paradiso. :)
Pero' punti critici continuano ad esserci, e illudersi che non esistano
non aiuta, mentre prevederli si'. :-) Quindi, temo, la risposta e' "no". 
-- 
Life's something u don't get out alive..
ObjectZone - 
http://space.tin.it/computer/csadun


Anche io, quindi scusami per la brevita' della risposta. Sto "traslocando" 
quasi totalmente (lavoro, citta, casa, ecc.ecc.) e quindi mi appoggio per le 
risposte dove posso (in questo caso mailgate + mail su un computer 
dell'ufficio vicino).
Secondo me tu stai affrontando il problema in modo sbagliato: il tuo scopo 
primario infatti deve essere quello di fornire delle funzionalita' per la 
tua applicazione, non quello di costruire il framework. Infatti, se ti fermi 
a considerare le funzionalita' sicuramente ce ne saranno alcune di lettura / 
scrittura / modifica verso il database: quelle devi rendere portabili. Il 
tuo design deve fare in modo che le modifiche si concentrino in punti ben 
precisi, e non in giro per tutto il codice.
Il consiglio che ti do e' quello di rendere totalmente indipendenti gli
stati applicativi che contengono la logica di business dal database,
isolandolo non dietro a un framework generico per l'accesso al DB ma
semplicemente dietro ad uno strato applicativo che di volta in volta
porterai verso il nuovo DB. Se poi nascera' un framework, si vedra' :-D.
Questo perche' puntando subito sul framework rischi di spenderci troppo,
mentre invece se ti concentri sulle funzionalita' spendi solo quello che
devi obbligatoriamente spendere.
Se vuoi approfondiamo, tieni solo conto del fatto che sono un po' "appeso" 
attualmente :-D
Ciao,
    Bruno.
|
| Bruno Bossola
| A Java Software Engineer :-)
| 
http://bbruno.fasturl.it/
|
| 
http://members.xoom.it/bbruno
| 
http://digilander.iol.it/bbossola
|
_________________________________________________________________
Get your FREE download of MSN Explorer at 
http://explorer.msn.com/intl.asp
-- 
Posted from [62.128.64.7] by way of 
f98.law4.hotmail.com
 [216.33.149.98] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG