JDBC API 給 Java 程式提供了一種訪問一個或者多個資料來源的途徑，在大多數情況下，資料來源是關係型資料庫，使用 SQL 語言來訪問。但是，JDBC Driver 也可以實現為能夠訪問其它型別的資料來源，比如說檔案系統或物件導向的系統。 JDBC API 最主要的動機就是提供一種標準的 API ，讓應用程式訪問多種多樣的資料來源。
這一章介紹了 JDBC API 的一些關鍵概念，此外，也介紹 JDBC 程式的兩種使用場景，分別是兩層模型和三層模型，在不同的場景中，JDBC API 的功能是不一樣的。
4.1 建立連線
JDBC API 定義了 Connection 介面來代表與某個資料來源的一條連線。
典型情況下，JDBC 應用可以使用以下兩種機制來與目標資料來源建立連線
DriverManager— 這個類從 JDBC API 1.0 版本開始就有了，當應用程式第一次嘗試去連線一個資料來源時，它需要指定一個url，DriverManager將會自動載入所有它能在 CLASSPATH 下找到的 JDBC 驅動（任何 JDBC API 4.0 版本前的驅動，需要手動去載入）。DataSource— 這個介面在 JDBC 2.0 Optionnal Package API 中首次被引進，更推薦使用DataSource， 因為它允許關於底層資料來源的具體資訊對於應用來說是透明的。需要設定DataSource物件的一些屬性，這樣才能讓它代表某個資料來源。當這個介面的getConnection方法被呼叫時，這個方法會返回一條與資料來源建立好的連線。應用程式可以通過改變DataSource物件的屬性，從而讓它指向不同的資料來源，無須改動應用程式碼；同時DataSource介面的具體實現類也可以在不改動應用程式程式碼的情況下，進行改變。
JDBC API 也對 DataSource 介面有兩方面的擴充套件，目的是為了支援企業應用，這兩個擴充套件的介面如下所示：
ConnectionPoolDataSource— 支援對物理連線的快取和重用，這能提高應用的效能和可擴充套件性XADataSource— 使連線能在分散式事務中使用
4.2 執行 SQL 並操作結果集
一旦建立好一個連線，應用程式便可以通過這條連線，呼叫響應的 API 來對底層的資料來源執行查詢或者更新操作， JDBC API 提供了對於 SQL2003 標準的實現的訪問。由於不同的廠商對這個標準的支援程度不同，所以 JDBC API 提供了 DatabaseMetadata 這個介面，應用程式可以使用這個介面來檢視某個特性是否受到底層資料庫的支援。JDBC API 也定義了轉義語法，允許應用程式去訪問一些非標準的、某個資料庫廠商獨有的特性。使用轉義語法能夠讓使用 JDBC API 的應用程式像原生應用程式一樣去訪問某些特性，並且也提高了應用的可移植性。
應用可以使用 Connection 介面中定義的方法，去指定事務的屬性，並建立 Statement 物件、PreparedStatement 物件，或者 CallableStatement 物件。 這些 statement 用來執行 SQL 語句，並獲取執行結果。ResultSet 介面包裝一次 SQL 查詢的結果。 statements 可以是批量的，應用能夠在一次執行中，向資料庫提交多條更新語句，作為一個執行單元。
JDBC API 的 ResultSet 介面擴充套件了 RowSet 介面，提供了一個功能更全面的對錶格型資料進行封裝和訪問的容器。一個 RowSet 物件是一個 Java Bean 元件，在於底層資料來源斷開連線的情況下，也能對資料進行操作，比如說，一個 RowSet 物件可以被序列化，然後通過網路傳送出去，這對於那些不想對錶格型資料進行處理的客戶端來說特別有用，並且無須在連線建立的情況下進行，就減輕了驅動程式的負擔。RowSet 的另外一個特性是，它能夠包含一個定製化的 reader，來對錶格型資料進行訪問，並非只能訪問關係型資料庫的資料。此外，一個 RowSet 物件，能在與資料來源斷開連線的情況下，對行資料進行改寫，並且能夠包含一個定製化的 writer，把改寫後的資料寫回底層的資料來源。
4.2.1 對 SQL 高階資料型別的支援
JDBC API 定義了 SQL 資料型別到 JDBC 資料型別的相互轉化規則，包括對 SQL2003 的高階資料型別的支援，比如說 BLOB, CLOB, ARRAY, REF, STRUCT, XML, DISTINCT。 JDBC 驅動的實現也可以定義個性化的轉化規則（user-defined types, UDTS）, 該使用者定義的UDT能夠對映到 Java 語言中的某個類。JDBC API 也提供了對外部資料的訪問，比如說儲存在檔案裡，但不受資料來源管理的資料。
4.3 兩層模型
兩層模型定義了客戶端層和服務端層，不同層實現不同的功能，如下圖所示:
客戶端層包含應用程式以及一個或者多個 JDBC 驅動，這一層的主要職責是：
表現層邏輯
業務邏輯
對於多語句事務或者分散式事務的事務管理
資源管理
在這種模型中，應用程式直接與 JDBC 驅動互動，包括建立和管理物理連線，處理底層資料庫的細節。應用程式可能會基於對底層資料來源的型別的認知，去訪問一些特有的、非標準的特性，以此來獲得效能上的提升。
這個模型有一些缺點，如下所示：
將表現層和業務層邏輯與底層的功能直接混合，這會使程式碼變得難以維護。
應用程式不具有可移植性，因為應用程式會使用到底層特定資料庫的一些獨有的特性，對於需要與多種資料來源進行連線的應用程式來說，要特別注意不同廠商的資料庫實現以及不同的特性。
限制了可擴充套件性。典型地，應用程式將會一直持久與資料庫的連線，直到應用程式退出，這就限制了併發訪問資料庫的併發數，在這種模型中，所謂的效能、可擴充套件性以及可用性，需要 JDBC 驅動以及底層的資料庫來共同保證。如果應用程式使用的 JDBC 驅動不止一種，那麼情況就會更加複雜。
4.4 三層模型
三層模型引進了一箇中間層，來處理業務邏輯並作為基礎設施，如下圖所示
這種架構對於企業應用來說，效能、可擴充套件性和可用性都得到提升，各層的職責如下所示：
客戶端層 — 僅作為表現層，只需要與中間層互動，而不須瞭解中間層的基礎架構以及底層資料來源的功能細節
-
中間層伺服器 — 包含以下幾個組成部分：
實現了業務邏輯，並與客戶端進行互動的應用程式。如果應用程式需要與底層資料來源互動，它只需要關注高層次的抽象和邏輯連線，若不是底層的驅動 API。
為應用程式提供基礎設施的應用伺服器。這些基礎設施包括對物理資料庫連線的池化和管理、事務管理，以及對不同驅動 API 的不同點進行遮蔽，最後一點使得我們很容易寫出可移植的應用程式，應用伺服器這個角色可以由 Java EE 伺服器來承擔，應用伺服器主要實現提供給應用程式使用的抽象層，並負責與 JDBC 驅動互動。
能夠與底層資料來源建立連線的 JDBC 驅動。每個驅動根據其底層資料來源的特性，去實現標準的 JDBC API，驅動層可能會遮蔽掉 SQL2003 標準與資料來源支援的 SQL 方言之間的不同。如果底層資料來源並不是一個關係型的資料庫，驅動需要去實現對應的關係層邏輯，提供給應用伺服器使用。
底層的資料來源 — 這一層是資料所在的一層，可以包含關係型資料庫，檔案系統，物件導向資料庫，資料倉儲等等任何能組織和表現資料的東西，但它們都需要提供符合 JDBC API 規範的驅動。
4.5 JDBC 與 JavaEE 平臺
Java EE 元件，比如說 JavaServer Pages、Servlets以及 EJB 元件，通常都需要使用 JDBC API 來訪問關係型的資料，當 Java EE 元件使用 JDBC API 時，它們的容器會管理事務以及資料來源。這意味著 Java EE 元件的開發者不會直接使用 JDBC API 的事務管理和資料來源管理的能力。更多內容，請參考 Java EE 平臺規範。