Il JDBC isola il programmatore
che sviluppa un’applicazione che interagisca con un database, da specifici
database vendor. L’applicazione utilizza
i nomi delle interfacce e i metodi descritti nelle API JDBC, ignorando
come vengano implementate nel driver e utilizzando le interfacce descritte nelle
API come se fossero implementazioni delle classi.
Consente allo sviluppatore di passare qualsiasi stringa direttamente al livello di driver.
Un driver JDBC è una collezione di classi che implementano le interfacce di JDBC per connettersi ad un database. È necessario fornire la classe che implementa l’interface java.sql.Driver
Il DriverManager è una classe che appartiene al package java.sql che impiega
la classe Driver quando necessita di collegarsi ad un particolare database,
referenziato tramite URL.
Attraverso il drive manager.
Contiene 18 interfacce in JDBC. Le principali sono:
 |
Driver |
|
Connection |
|
Statement |
|
ResultSet |
|
DriverManager |
Il flusso descrive come consentire al programmatore di aprire una connessione ad uno specifico DB, eseguire statement SQL e elaborare il risultato ottenuto.
-una stringa URL viene passata come parametro al metodo getConnection della classe DriverManager, che si occupa di recuperare l’opportuno Driver.
-Il Driver apre una connessione al database, ovvero si ottiene un oggetto di tipo Connection.
-Grazie alla Connection si ottiene uno Statement.
-Lo Statement viene eseguito grazie al metodo executeQuery che restituisce sempre un oggetto ResultSet; nel caso di un operazione di insert o update l’oggetto ResultSet non contiene dati.
I cinque principali compiti sono:
creare un istanza di un driver JDBC
specificare un database
aprire una connessione ad un database
inviare una query
ricevere un risultato e processarlo
Si specifica un URL indicandone il tipo con la sintassi:
jdbc: subprotocol : parameters
Esempio di accesso di JDBC a mSQL:
String url = arg[0]; //passato da riga di comando
String url = “jdbc : msql : //” + serverName + “ : 4333/prodotti”;
Esempio utilizzando il bridge JDBC-ODBC :
jdbc : odbc : Object.prodotti
Il passaggio di una Query avviene
- creando l’object Statement utilizzando il metodo createStatement() su un oggetto Connection. Viene racchiuso in un blocco try-catch che lancia SQL exception si ha quando c’è un errore di accesso al database: es se si interrompe la connessione:
try {
stmt = con.createStatement();
}
catch (SQLException exp) {
System.out.println(exp.getMessage()) ;
}
-inviare lo statement SQL al database
ResultSet res =
stmt.executeQuery(“ select * from prodotti order by DESCRIZIONE”);
si processa il risultato:
-accedendo alla tabelle dei risultati utilizzando l’object java.sql.ResultSet
-si utilizzano i metodi getxxx di un object ResultSet
Vi sono due principali tipi di Statement.
-Prepared Statement.
L’oggetto di tipo PreparedStatement viene utilizzato quando la stessa query SQL deve essere eseguita più volte.
La classe Prepared Statement estende la classe Statement aggiungendo la possibilità di dare un valore a parametri all’interno dello statement.
Es:
public boolean prepStatement(Float ID, String DESCRIZIONE)
{
PreparedStatement ps = con. PreparedStatement(“ update Prodotti
set
DESCRIZIONE =? Where
ID = ? );
ps.setFloat(1, ID);
ps.setsTRING(1, DESCRIZIONE);
int rowUpdate =
ps.executeUpdate();
return (rowUpdate > 0 );
}
-Callable
Statement.
Un Callable Statement consente l’esecuzione di non-SQL statement(es.store procedure) di essere eseguite.
Callable Statement estende PrepareStatement che fornisce metodi per settare i parametri di ingresso.
Per recuperare più risultati ho il metodo getMoreResults.
Es.
String DESCRIZIONE = “mouse”;
CallableStatement cs = con.prepareCall(“{call return_ID(?,?) }”)
try
{
cs.setString(1, DESCRIZIONE);
cs.registerOutParameter(2, java.sql.Type.REAL);
cs.execute();
float ID = cs.getFloat(2);
} catch (SQLException exp) {
System.out.println(“Query fallita!”) ;
exp.printStackTrace();
}
•
Tipo 1 - JDBC-ODBC Bridge
•
Tipo 2 - Basato su Native API
•
Tipo 3 - JDBC-Net
• Tipo 4 - Protocollo Nativo
Il cliente deve
acquistare il driver ODBC.
Fornito da Sun
JavaSoft (utilizzato con il driver ODBC fornito da altri)
• Il Bridge è
indipendente dal database.
Può accedere
qualsiasi database che abbia il supporto ODBC (anche non-relational database).
• Il meno
efficiente — si passa attraverso JDBC e ODBC.
• Richiede JDBC,
JDBC-ODBC bridge, ODBC manager, e driver ODBC sul lato client.
• Richiede un diverso driver ODBC per ogni database.
Parzialmente scritto
in Java.
Fornito da
tipici database vendor
• Weblogic
• Driver è
specifico del database.
• Driver converte
JDBC a chiamate native proprietarie del database (ad esempio, Oracle CLI o
Sybase Open Client).
• Buone
performance.
• Richiede JDBC
manager, JDBC driver, e librerie native del database sul client.
• Richiede un diverso driver nativo per ogni database.
Java software.
Fornito da tipici
database vendor
• Driver scritto
in Java.
• Driver è
database independent—tutti i driver utilizzano lo stesso protocollo dal client
al server.
• JDBC manager,
JDBC driver, e librerie native del database sul secondo livello (tier two).
• Scalabile—
driver ottimale per architetture three-tier.
• Driver converte
JDBC a chiamate native proprietarie del database (ad esempio, Oracle CLI o
Sybase Open Client).
• Accesso a più back-end database utilizzando prodotti che fungono da database gateway.
Java software.
Fornito da tipici
database vendor
• Driver scritto
in Java.
• Driver è
specifico al database.
• Driver converte
JDBC a chiamate native proprietarie del database.
• Buone
performance.
• Richiede JDBC manager, driver e librerie native del database sul client.
Sono indipendenti dal database il JDBC-ODBC Bridge e JDBC-Net, mentre sono specifici del database
il driver Basato su Native API e Protocollo Nativo.
JDBC-ODBC Bridge,
JDBC-Net e Protocollo
Nativo hanno JDBC driver e librerie del database sul client, mentre il
driver basato su Native API ha JDBC sul client, librerie del database
sul two tier.
• Valutare e
controllare le caratteristiche del database
• Determinare se
il fornitore di database management system (DBMS) fornisce un driver JDBC
• Determinare il
tipo di driver fornito/i
• Tipo 1 ha basse
performance dovute all’overhead di traduzione.
• Tipo 2 converte
chiamate JDBC in chiamate native del database (Oracle’s SQL*Net, INFORMIX
I-Connect o Sybase OpenClient, ecc.) che sono inviate sulla rete al database
server.
• Tipo 3 converte
chiamate JDBC in un database-independent formato di rete che è iniviato sulla
rete ad un application
server. L’application
server converte le richieste in un protocollo specifico del database. Questo
tipo di driver è la soluzione ottimale per una progettazione three-tier delle
applicazioni. Possono insorgere problemi legati al protocollo di rete
attreaverso i firewall.
• Tipo 4 converte chiamate JDBC in invocazioni di chiamate su protocollo nativo utilizzato dal database. Questo consente un’inovazione diretta tra il client (o application server) ed il database. Questo tipo di driver si dimostra una soluzione molto valida se l’azienda ha definito un fornitore di database come standard e il fornitore mette a disposizione un driver di tipo 4. Possono insorgere problemi legati al protocollo di rete attraverso i firewall.
Se non trovate
driver per il vostro database forniti dal DB vendor o da terze parti:
• Acquiste un
database gateway che possieda un JDBC driver ed il mapping per il vostro
database.
I Database gateway
effettuano il mapping di database non-relazionali e di file a dati in forma
relazionale. Questi prodotti consentono accesso concorrente a più file e
database, offrendo un immagine di dati complessiva ( “joined data”) nella
forma di una tabella relazionale.
Utilizzate un
JDBC-ODBC bridge.
• Valutate
modalità alternative di interfacciare la sorgente dei dati (object wrapper,
codice nativo oppure API pubblicate come socket e IBM LU6.2).
• Valutate modalità alternative per memorizzare i dati (object database management systems [ODBMS]).
Fornitori di
Gateway DB sono:
• IBM
• Information Builders
• Sybase
• Intersolv