[Java/JDBC] Dove memorizzo l'SQL?

[GByTe87]

Buonasera :D

Scrivo in Java da poco, quindi sto cercando di far mie le "best pratices" mano a mano che mi si pongono i problemi. :D

Ora, il dubbio è questo: sto scrivendo un'applicazione in java che si interfaccia con un DB Oracle, ad un livello di interazione tale per cui ORM e simili sono un po' troppo overkill imho. (anche perchè al mio livello attuale ci metterei più tempo a capire come utilizzare l'eventuale framework che altro..).

Per "modellare" rapidamente il codice ho creato una classe SQL che contiene vari membri statici di tipo string, uno per ogni statement. Giusto per riunire il codice SQL in un'unico posto.

Ora, vorrei fare qualcosa di più elegante; avete qualche consiglio in merito? Avevo pensato di racchiudere le query in vari file *.sql in una dir nei pressi del jar di esecuzione, in modo da poterli modificare / ottimizzare senza ricompilare il codice.

Che ne dite? Consigli, critiche e insulti accettati. :D

Grazie :)

[tacchinox]

Ciao, ti diro' che a me la classe statica piace.
Io scrivo spesso metodi tipo questo in c#, ma non dovrebbe essere troppo differente in Java:

public static DataTable GetTabellaUtenti()
{
string query = "SELECT * FROM Utenti";
return ExecuteQuery(query);
}

Dove ExecuteQuery è il metodo che gestisce tutta la comunicazione e gli errori con il database.
tipo:
private DataTable ExecuteQuery(string query)
{
Connection conn = new Connection();
try{
etc...
}
catch {display exception}
finally{close connection}
}

L'ho visto fare anche in alcuni video di sviluppatori e mi trovo bene anche perche' arrivo subito alla query, senza dover aprire file di testo e doverli gestire.

[GByTe87]

Anche a me inizialmente piaceva questo approccio, la cosa che mi "spaventa" è che per ogni modifica minima al db bisogna ricompilare tutto. :)

[WarDuck]

L'alternativa sarebbe usare delle Stored Procedures, ovvero creare delle funzioni direttamente nel DB in maniera tale da poterle richiamare con una SELECT semplice.

Il vantaggio è che nel codice avresti solo questo tipo di chiamate, passando eventualmente dei parametri, e giustamente tutto ciò che ha a che fare con il DB è nel DB.

Tra l'altro quest'approccio è tipicamente più sicuro, perché la Stored Procedure accetta solo i parametri che dici te, senza troppi rischi sul piano dell'SQL injection.

Ora, se cambi dettagli interni quest'approccio ti garantisce comunque compatibilità con l'applicazione esistente, ma ovviamente se fai modifiche più consistenti tali da modificare anche i parametri che passi alle funzioni sei comunque costretto a modificare le chiamate nel codice.

In questo senso secondo me la cosa ideale è spendere molto tempo nella fase di progettazione del DB, affinché questo tipo di rischi sia minimizzato.

Un altro svantaggio è che se cambi DB potresti dover ri-scrivere le procedure (anche se credo che per cose non troppo complesse le varie sintassi si equivalgono).

Un'altra possibilità è invece raggruppare le query nella classe che gestisce quel tipo di oggetto, quindi farti una specie di ORM su misura.