Esistono vari modi per connettersi a un database relazionale per archiviare e recuperare informazioni. A seconda delle tue esigenze puoi procedere con un'implementazione di basso livello o una versione più alta.
Potresti utilizzare direttamente JDBC . Hai bisogno di un driver che sappia come parlare al tuo particolare database, apri una connessione, prepari una dichiarazione con alcune query SQL, imposta i parametri necessari per l'istruzione (se presente), esegue l'istruzione, recupera un set di risultati, itera il set di risultati per creare oggetti dai risultati, quindi chiude le risorse che hai utilizzato (set di risultati, istruzione , connessione).
Questo è il modo più basso per farlo. Ma ha alcuni svantaggi:
- Il codice della piastra di caldaia è molto elevato: ottieni connessione, crea istruzioni, esegui istruzioni, passa in rassegna i risultati, costruisci oggetti, rilascia risorse utilizzate. Devi fare queste ogni volta che vuoi eseguire alcuni SQL. Solo SQL è diverso ogni volta, il resto lo devi fare ancora, ancora e ancora.
- si apre una connessione al database ogni volta che si esegue una query. C'è un sovraccarico in questo e, a seconda di quante query si eseguono alla volta, si potrebbe finire per aprire troppe connessioni. Alcuni database potrebbero avere limitazioni per client, quindi non puoi andare troppo in alto.
Per limitare le connessioni aperte potresti utilizzare un pool di connessioni come Apache DBCP, C3P0, HikariCP, ecc. Hai ancora lo stesso codice della piastra di riscaldamento, ma ora invece di creare e chiudere una connessione, prendi in prestito e restituisci uno al pool. Più efficiente.
Ora, dal momento che il piatto della caldaia è sempre lo stesso, perché non spostarlo in qualche framework o libreria che lo fa per te e ti concentri solo a scrivere l'SQL. Questo è ciò che fa un mappatore di dati come MyBatis , ad esempio. Lo si configura una volta, si scrivono gli SQL necessari e si associano ai metodi, si dice a MyBatis come mappare il risultato da una riga all'altra e tutta la piastra della caldaia viene gestita da MyBatis. Esegui un metodo e recupera gli oggetti che desideri.
Con MyBatis hai solo bisogno di scrivere l'SQL. Ma alcune persone non vogliono nemmeno preoccuparsene. Hai codice della piastra della caldaia e le connessioni gestite da qualche libreria / framework per te, ma perché non eliminare anche SQL?
Questo è ciò che ORM come fa Hibernate. Si associano le classi alle tabelle e poi Hibernate gestisce tutto per te. Genera l'SQL necessario quando si desidera salvare o recuperare i dati dal database. Una volta configurato Hibernate, puoi fingere che il database non esista (almeno per un po ').
Ciascuno di questi metodi presenta vantaggi e svantaggi.
- con JDBC devi scrivere molto codice della piastra, gestire le transazioni da solo, assicurarti di non perdere le risorse, ecc. È di basso livello;
- con i mapper dei dati è necessario scrivere gli SQL. Il data mapper non pretende che non ci sia un database, devi affrontarlo.
- con gli ORM puoi fingere che non ci sia alcun database relazionale coinvolto. Hai a che fare solo con gli oggetti. Gli ORM sono ideali per le applicazioni CRUD ma per gli altri, un ORM potrebbe metterti nei guai. C'è questa cosa chiamata disadattamento dell'impedenza relazionale-oggetto che mostra la sua brutta testa. E quando lo fa, le prestazioni sono di solito la prima cosa che va a finire.
Queste sono le tue opzioni. Guarda la tua applicazione e vedi quale soluzione potrebbe essere più appropriata. Considerando la tua domanda, potresti voler usare qualcosa di leggero (non basso come JDBC diretto, e non tanto alto quanto Hibernate).
Ma non reinventare la ruota . Qualcosa come Commons DbUtils per esempio può essere un buon punto di partenza. Prende il codice piastra caldaia JDBC lontano da te, senza modificare / aggiungere molto al modo in cui interagisci con un database.