5.2　JDBC的核心概念

JDBC API給Java程序提供了一種訪問一個或者多個數據源的途徑，在大多數情況下，數據源是關系型數據庫，使用SQL語言來訪問。但是，JDBC Driver也可以實現為能夠訪問其他類型的數據源，比如文件系統或面向對象系統。JDBC API主要的動機就是提供一種標準的API，讓應用程序訪問多種多樣的數據源。

本節介紹JDBC API的一些核心概念，此外，也介紹JDBC程序的兩種使用場景，分別是兩層模型和三層模型，在不同的場景中，JDBC API的功能是不一樣的。

5.2.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：使連接能在分布式事務中使用。

以下是JDBC客戶端從DriverManager獲取連接的例子：

5.2.2　執行SQL并操作結果集

一旦建立好一個連接，應用程序便可以通過這條連接調用響應的API來對底層的數據源執行查詢或者更新操作，JDBC API提供了對于SQL:2003標準實現的訪問，支持BLOB、CLOB、ARRAY、REF、STRUCT、XML、DISTINCT等高級數據類型。由于不同的廠商對這個標準的支持程度不同，因此JDBC API提供了DatabaseMetadata這個接口，應用程序可以使用這個接口來查看某個特性是否受到底層數據庫的支持。JDBC API也定義了轉義語法，允許應用程序訪問一些非標準的、某個數據庫廠商獨有的特性。使用轉義語法能夠讓使用JDBC API的應用程序像原生應用程序一樣去訪問某些特性，并且也提高了應用的可移植性。

應用可以使用Connection接口中定義的方法去指定事務的屬性，并創建Statement對象、PreparedStatement對象或者CallableStatement對象。這些Statement對象用來執行SQL語句，并獲取執行結果。ResultSet接口包裝一次SQL查詢的結果。Statement可以是批量的，應用能夠在一次執行中向數據庫提交多條更新語句作為一個執行單元。

JDBC API的ResultSet接口擴展了RowSet接口，提供了一個功能更全面的對表格型數據進行封裝和訪問的容器。一個RowSet對象是一個Java Bean組件，在底層數據源斷開連接的情況下也能對數據進行操作，比如一個RowSet對象可以被序列化，然后通過網絡發送出去，這對于那些不想對表格型數據進行處理的客戶端來說特別有用，并且無須在連接建立的情況下進行，就減輕了驅動程序的負擔。RowSet的另一個特性是，它能夠包含一個定制化的reader，來對表格型數據進行訪問，并非只能訪問關系型數據庫的數據。此外，一個RowSet對象能在與數據源斷開連接的情況下對行數據進行改寫，并且能夠包含一個定制化的writer，把改寫后的數據寫回底層的數據源。

以下是一個執行SQL并操作結果集的例子：

5.2.3　兩層模型

兩層模型定義了客戶端層和服務端層，不同層實現不同的功能，如圖5-1所示。

客戶端層包含應用程序以及一個或者多個JDBC驅動，這一層的主要職責是：

• 表現層邏輯。
• 業務邏輯。
• 對于多語句事務或者分布式事務的事務管理。
• 資源管理。

在這種模型中，應用程序直接與JDBC驅動交互，包括創建和管理物理連接、處理底層數據庫的細節。應用程序可能會基于對底層數據源類型的認知去訪問一些特有的、非標準的特性，以此來獲得性能上的提升。

這種模型有一些缺點，說明如下：

• 將表現層和業務層邏輯與底層的功能直接混合，這會使代碼變得難以維護。
• 應用程序不具有可移植性，因為應用程序會使用到底層特定數據庫的一些獨有的特性，對于需要與多種數據源進行連接的應用程序來說，要特別注意不同廠商的數據庫實現以及不同的特性。
• 限制了可擴展性。典型地，應用程序將會一直持久地與數據庫連接，直到應用程序退出，這就限制了并發訪問數據庫的并發數，在這種模型中，所謂的性能、可擴展性以及可用性需要JDBC驅動以及底層的數據庫來共同保證。如果應用程序使用的JDBC驅動不止一種，情況就會更加復雜。

5.2.4　三層模型

三層模型引進了一個中間層來處理業務邏輯并作為基礎設施，如圖5-2所示。

這種架構對于企業應用來說，性能、可擴展性和可用性都會得到提升，各層的職責如下：

• 客戶端層：僅作為表現層，只需要與中間層交互，而不需要了解中間層的基礎架構以及底層數據源的功能細節。
• 中間層服務器：包含以下幾個組成部分：

　實現了業務邏輯，并與客戶端進行交互的應用程序。如果應用程序需要與底層數據源交互，那么它只需要關注高層次的抽象和邏輯連接，而不是底層的驅動API。

　為應用程序提供基礎設施的應用服務器。這些基礎設施包括對物理數據庫連接的池化和管理、事務管理以及對不同驅動API的不同點進行屏蔽，最后一點使得我們很容易寫出可移植的應用程序，應用服務器這個角色可以由Java EE服務器來承擔，應用服務器主要實現提供給應用程序使用的抽象層，并負責與JDBC驅動交互。

　能夠與底層數據源建立連接的JDBC驅動。每個驅動根據其底層數據源的特性實現標準的JDBC API，驅動層可能會屏蔽掉SQL:2003標準與數據源支持的SQL方言之間的不同。如果底層數據源并不是一個關系型的數據庫，驅動就需要實現對應的關系層邏輯，提供給應用服務器使用。

• 底層的數據源：這一層是數據所在的一層，可以包含關系型數據庫、文件系統、面向對象數據庫、數據倉庫等任何能組織和表現數據的東西，但它們都需要提供符合JDBC API規范的驅動。

5.2.5　JDBC與Java EE平臺的關系

Java EE組件（比如Java Server Pages、Servlet以及EJB組件）通常需要使用JDBC API來訪問關系型的數據，當Java EE組件使用JDBC API時，它們的容器會管理事務以及數據源。這意味著Java EE組件的開發者不會直接使用JDBC API的事務管理和數據源管理的能力。