DadaLilli ha scritto:
è possibile usare tante query in un solo metodo?
Generalmente in una classe "DAO" ciascun metodo fa solo
una (1) query su DB e basta. Ma perché tipicamente si fa così ...
Poi, sempre generalmente/tipicamente, è uno strato "superiore" (es. un "Service", nell'accezione di Spring Framework) che mette insieme più chiamate a uno o più metodi di uno o più DAO.
E in tutto quello che hai scritto finora, presumo che non hai considerato una cosa importante. Quando si fa questa "classica" implementazione del trasferimento da un conto ad un altro, deve essere fatto tutto in maniera "transazionale". Ovvero come si dice, si deve seguire l'approccio "o tutto o niente".
Se il update per togliere 100 euro dal conto A ha successo ma il update per aggiungere i 100 Euro al conto B
fallisce, deve essere fatto un "rollback" perché il primo update deve essere annullato. Solo se entrambi gli update hanno successo allora si fa il "commit" delle modifiche su DB. Altrimenti deve apparire come se nulla sia stato fatto (appunto:
o tutto o niente).
DadaLilli ha scritto:
Perchè se così fosse io ci ho provato ma mi sono fermat perchè sembra venga fuori un metodo chilometrico, dovrei dichiarare un result set per ogni query e dovrei fare un blocco try-catch-finally per ogni operazione. Quindi mi chiedevo se ci fosse un modo migliore per poter fare questa cosa.
Certo che si può fare di meglio: se l'applicazione ha tante query, può aver senso usare/realizzare uno "strato" apposito per nascondere tutta la parte "intricata" e ripetitiva di JDBC. Ovvero si realizza quello che si definisce un "template", uno scheletro di codice che gestisce il flusso generale per fare la query con JDBC che sostanzialmente rappresenta tutto ciò che NON cambia da una query all'altra. E poi si rende parametrabile/configurabile ciò che invece cambia da una query all'altra.
Quando si usa Spring Framework ad esempio si possono usare i JDBC template di Spring. Se nella tua applicazione stai usando JDBC "da zero" senza l'uso di librerie/framework particolari, ovviamente non c'è nulla di già fatto in questo senso dei template. Ma un sistema di "template" anche basilare/minimale lo si può realizzare. Per farlo serve avere buone basi sulla OOP e possono essere utili le interfacce e la conoscenza dei design pattern in generale. E anche la conoscenza dei
generics risulta utile, specialmente per la parte di mappatura del ResultSet, al fine di fare una logica che sia generica e riutilizzabile.
E se si può usare almeno Java 8, allora tutte le belle novità,
functional interfaces,
lambda expression,
method references, ecc... diventano anche questi moooolto utili!