Newsgroup: it.comp.java
Titolo: [NEWBIE] Hibernate o JDBC su DB con Stored

Come da topic sono un novello :) e per un progetto d'esame mi e' stato
dato un DB che per me ha tutte le sembianze di un'applicazione, poiche'
oltre alla sua struttura tabellare e' pieno zeppo di stored proc che
eseguono tutte le attivita' di CRUD, dunque compreso il semplice recupero
di dati. La ragione credo sia stata per snellire il codice di business
dell'intero progetto, potendo fare determinate modifiche senza necessita'
di ricompilazione o meglio modifica script, visto che il motore attuale
che usa il db e' PHP. Il progetto prevede il "porting" in J2EE, e mi
chiedevo per la parte model se agganciarmi con JDBC, o implementare
Hibernate. Ma in quest'ultimo caso ho il dubbio se continuare a lavorare
con le SP oppure dropparle ed implementarle da codice. Suggerimenti ? 
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

La strategia di mettere su stored procedure la logica applicativa e' una str*****a che si vede molto spesso.
Come hai detto, il vantaggio e' che si puo' modificare la logica senza dover ricompilare; ma e' l'unico vantaggio. Gli svantaggi sono innumerevoli, ma il piu' delle volte vengono ignorati o non compresi da chi deve fare questo tipo di scelte; tra questi ci sono:
- legame indissolubile col vendor del database utilizzato
- difficolta' nel debugging: devi gestire un sistema di debugging che ti permetta di agire sia sull'applicazione che sul database
- se cambia una colonna o un legame tra le tabelle, devi cercare tutte le procedure che ne fanno uso e modificarle di conseguenza
- e' macchinoso integrare e gestire il codice delle stored procedure nel VCS insieme ai sorgenti dell'applicazione
- se vuoi ad esempio cercare tutti i punti nel programma dove viene impostato il "nome del cliente", non puoi sfruttare i comodi tool che sono solitamente presenti in tutti gli IDE
- gestire la modallizzazione tramite ORM e' piu' laborioso e error-prone, e non sempre potrai utilizzare tutte le feature che mettono a disposizione
- la modellizzazione diventa un processo meno naturale e piu' dispendioso: un'applicazione fatta a stored procedure induce a creare un metodo Java per ogni stored procedure, dove i parametri del metodo sono gli stessi della stored procedure. Usando questo punto di vista, il modello diventa un'accessorio inutile.
Queste sono le cose che mi sono venute in mente adesso, ma ce ne sono sicuramente mille altre che magari qualcun altro si divertira' ad elencare.
Il mio consiglio e', come avrai potuto intuire, quello di gestire la logica applicativa direttamente nel codice Java, e lasciare gestire ad un ORM (come Hibernate) la problematica di comunicare col database.
Anche se reciclando le stored procedure che gia' ci sono ridurresti di molto la mole di lavoro, puntando su questa nuova strada ne guadagneresti in solidita', manutenzione e leggibilita'.
-- 
SoulSpirit

Non potevo ricevere risposta migliore, esaustiva e convincente. La mia
fortuna e' che trattandosi di un piccolo progetto, cio' che attualmente
sta in piedi e' una manciata di SP, pertanto il tempo necessario per la
trascrizione di queste non dovrebbe essere una discriminante decisionale,
insomma lo spero :) Capito che il tutto va a favore di stabilita',
manutenibilita' ed altro, pero' a volte, purtroppo, si mangia con le pezze
a colori :) 


 str*****a che si vede molto spesso. Come hai detto, il vantaggio e' che
Fighi, ti ringrazio mi stai rincuorando, perchè sto giusto giusto 
lavorando con un tizio che ..lavora così e mi sta rinconglionendo.
Standing ovation ...