Newsgroup: it.comp.java
Titolo: gestire le "piccole" modifiche critiche

Ciao,
mettiamo di avere una applicazione web che fa da interfaccia completa
(inserimento/cancellazione/modifica) ad un database gestendo quindi le
relazioni e le associazioni tra le entità (concorrenza, transazioni etc.).
Questa applicazione può esser stata scritta con ejb, per esempio.
Mettiamo che un bel giorno, una delle tabelle "al centro" del sistema
informativo abbia bisogno di un nuovo campo in chiave primaria. L'effetto è
che bisogna
-cambiare la tabella in questione e tutte le tabelle legate
-cambiare tutti gli EJB/JavaBeans/JSP che hanno a che fare con questa
tabella
-ritestare mezzo (o tutto...) l' applicativo, sia fuzionalmente (a manina)
che con programmi di test, che tra l'altro dovrò anche aggiornare (ne ho
pochini ma ce li ho) .
questo, "solo" per aggiungere un campo a una tabella...
C'è qualcosa di sbagliato nel mio design?
C'è un modo per prevenire cose del genere (è la seconda volta che mi
capita), esiste un "pattern" in grado di prevenire modifiche così vaste per
esigenze così modeste?
Il guaio è dover giustificare certe tempistiche "solo" per un campo in più,
poi non dimentichiamoci che lavorando ad oggetti, c'è chi pensa che
"sviluppiamo visuale"  che non ho ancora ben capito cosa vuol dire, e
facciamo modifiche al volo.
Ciao.
Luigi.

 C'č un modo per prevenire cose del genere (č la seconda volta che mi
Si', fare bene l'analisi e progettare le cose in modo da poterle estendere.
Nella documentazione specificare bene cosa si puo' e cosa non si puo'
fare.
Davide

 > C'è un modo per prevenire cose del genere (è la seconda volta che mi


-ritestare mezzo (o tutto...) l' applicativo, sia fuzionalmente (a manina)
mi sa che stai soffrendo di questo problema. 
Ciao,
    Bruno.
---
| Bruno Bossola
| A Java Software Engineer :-)
| 
http://digilander.iol.it/bbossola

 perche' una singola modifica si ripercuote "a cascata" su tutti gli altri
componenti.
Sulle tabelle, purtroppo non c'è molto da fare (soprattutto se te le passano
già fatte), sui bean, è anche vero che ho molte classi accoppiate, perché
sul lato server ho degli entitybeans e sul lato web uso dei javabeans come
valueobject che vengono passati a dei sessionbean che ne gestiscono la
persistenza. di conseguenza i value object sono l'immagine 'riflessa' degli
entity (quindi molto accoppiati).
Boh, sarò più fortunato la prossima volta :-)
Chissà che i db ad oggetti siano la soluzione di questi problemi... non li
ho mai usati.
Gigi

 esigenze così modeste?
Io sono alle prime armi con Java ma posso consigliarti di leggere degli
estratti dai libri di Scott Ambler che parlano del mapping degli oggetti
ad un database relazionale oltre a tutta una serie di tecniche per
prevenire problemi come quelli che hai tu adesso.
http://www.ambysoft.com/mappingObjects.pdf
http://www.ambysoft.com/persistenceLayer.pdf
Andrea

dò uno sguardo.
Luigi

bel sito, consiglio la visione.

 Luigi
--------------------------------
Andrea Musumeci
java programmer free lance
cell: 347 0755781
http://www.javalab.it
--------------------------------

 vaste per esigenze cosě modeste?
In generale, incapsulare, localizzare, e disaccoppiare. 
-- 
Life's something u don't get out alive..
ObjectZone - 
http://space.tin.it/computer/csadun

 Ma io credevo che se uno paga può far di tutto... Mi stavo sbagliando? ;)
Sì sono d'accordo tutto si può fare. Col tempo e la pazienza si riesce poi
anche a farlo funzionare ;-)
Ciao
Luigi