JDBC 抽象和數(shù)據(jù)存儲異常層次
數(shù)據(jù)訪問是Spring 的另一個閃光點。
JDBC 提供了還算不錯的數(shù)據(jù)庫抽象，但是需要用痛苦的API。這些問題包括：
需要冗長的錯誤處理代碼來確保ResultSets，Statements以及（最重要的）Connections在使用后關(guān)閉。這意味著對JDBC的正確使用可以快速地導致大量的代碼量。它還是一個常見的錯誤來源。Connection leak可以在有負載的情況下快速宕掉應用程序。
SQLException相對來說不能說明任何問題。JDBC不提供異常的層次，而是用拋出SQLException來響應所有的錯誤。找出到底哪里出錯了——例如，問題是死鎖還是無效的SQL？——要去檢查SQLState或錯誤代碼。這意味著這些值在數(shù)據(jù)庫之間是變化的。
Spring用兩種方法解決這些問題：
提供API，把冗長乏味和容易出錯的異常處理從程序代碼移到框架之中?？蚣芴幚硭械漠惓Ｌ幚恚怀绦虼a能夠集中精力于編寫恰當?shù)腟QL和提取結(jié)果上。
為你本要處理SQLException程序代碼提供有意義的異常層次。當Spring第一次從數(shù)據(jù)源取得一個連接時，它檢查元數(shù)據(jù)以確定數(shù)據(jù)庫。它使用這些信息把SQLException映射為自己從org.springframework.dao.DataAccessException派生下來的類層次中正確的異常。因而你的代碼可以與有意義的異常打交道，并且不需要為私有的SQLState或者錯誤碼擔心。Spring的數(shù)據(jù)訪問異常不是JDBC特有的，因而你的DAO并不一定會因為它們可能拋出的異常而綁死在JDBC上。
Spring提供兩層JDBC API。第一個時，在org.springframework.jdbc.core包中，使用回調(diào)機制移動控制權(quán)——并且因而把錯誤處理和連接獲取和釋放——從程序的代碼移到了框架之中。這是一種不同的Inversion of Control，但是和用于配置管理的幾乎有同等重要的意義。
Spring使用類似的回調(diào)機制關(guān)注其他包含特殊獲取和清理資源步驟的API，例如JDO（獲取和釋放是由PersistenceManager完成的），事務管理（使用JTA）和JNDI。Spring中完成這些回調(diào)的類被稱作template。
例如，Spring的JdbcTemplate對象能夠用于執(zhí)行SQL查詢并且在如下的列表中保存結(jié)果：
| 代碼: |
JdbcTemplate template = new JdbcTemplate(dataSource);
final List names = new LinkedList();
template.query("SELECT USER.NAME FROM USER",
new RowCallbackHandler() {
public void processRow(ResultSet rs) throws SQLException {
names.add(rs.getString(1));
}
}); |
注意回調(diào)中的程序代碼是能夠自由拋出SQLException的：Spring將會捕捉到這些異常并且用自己的類層次重新拋出。程序的開發(fā)者可以選擇哪個異常，如果有的話，被捕捉然后處理。
JdbcTemplate提供許多支持不同情景包括prepared statements和批量更新的方法。Spring的JDBC抽象有比起標準JDBC來說性能損失非常小，甚至在當應用中需要的結(jié)果集數(shù)量很大的時候。
在org.springframework.jdbc.object包中是對JDBC的更高層次的抽象。這是建立在核心的JDBC回調(diào)功能基礎(chǔ)紙上的，但是提供了一個能夠?qū)DBMS操作——無論是查詢，更新或者是存儲過程——使用Java對象來建模的API。這個API部分是受到JDO查詢API的影響，我發(fā)現(xiàn)它直觀而且非常有用。
一個用于返回User對象的查詢對象可能是這樣的：
| 代碼: |
class UserQuery extends MappingSqlQuery {
public UserQuery(DataSource datasource) {
super(datasource, "SELECT * FROM PUB_USER_ADDRESS WHERE USER_ID = ?");
declareParameter(new SqlParameter(Types.NUMERIC));
compile();
}
// Map a result set row to a Java object
protected Object mapRow(ResultSet rs, int rownum) throws SQLException {
User user = new User();
user.setId(rs.getLong("USER_ID"));
user.setForename(rs.getString("FORENAME"));
return user;
}
public User findUser(long id) {
// Use superclass convenience method to provide strong typing
return (User) findObject(id);
}
}
|
這個類可以在下面用上：
| 代碼: |
User user = userQuery.findUser(25);
|
這樣的對象經(jīng)?？梢杂米鱀AO的inner class。它們是線程安全的，除非子類作了一些超出常規(guī)的事情。
在org.springframework.jdbc.object包中另一個重要的類是StoredProcedure類。Spring讓存儲過程通過帶有一個業(yè)務方法的Java類進行代理。如果你喜歡的話，你可以定義一個存儲過程實現(xiàn)的接口，意味著你能夠把你的程序代碼從對存儲過程的依賴中完全解脫出來。
Spring數(shù)據(jù)訪問異常層次是基于unchecked（運行時）exception的。在幾個工程中使用了Spring之后，我越來越確信這個決定是正確的。
數(shù)據(jù)訪問異常一般是不可恢復的。例如，如果我們不能鏈接到數(shù)據(jù)庫，某個業(yè)務對象很有可能就不能完成要解決的問題了。一個可能的異常是optimistic locking violation，但是不是所有的程序使用optimistic locking。強制編寫捕捉其無法有效處理的致命的異常通常是不好的。讓它們傳播到上層的handler，比如servlet或者EJB 容器通常更加合適。所有的Spring對象訪問異常都是DataAccessException的子類，因而如果我們確實選擇了捕捉所有的Spring數(shù)據(jù)訪問異常，我們可以很容易做到這點。
注意如果我們確實需要從unchecked數(shù)據(jù)訪問異常中恢復，我們?nèi)匀豢梢赃@么做。我們可以編寫代碼僅僅處理可恢復的情況。例如，如果我們認為只有optimistic locking violation是可恢復的，我們可以在Spring的DAO中如下這么寫：
| 代碼: |
try {
// do work
}
catch (OptimisticLockingFailureException ex) {
// I'm interested in this
}
|
如果Spring的數(shù)據(jù)訪問異常是checked的，我們需要編寫如下的代碼。注意我們還是可以選擇這么寫：
| 代碼: |
try {
// do work
}
catch (OptimisticLockingFailureException ex) {
// I'm interested in this
}
catch (DataAccessException ex) {
// Fatal; just rethrow it
}
|
第一個例子的潛在缺陷是——編譯器不能強制處理可能的可恢復的異?！@對于第二個也是如此。因為我們被強制捕捉base exception（DataAccessException），編譯器不會強制對子類（OptimisticLockingFailureException）的檢查。因而編譯器可能強制我們編寫處理不可恢復問題的代碼，但是對于強制我們處理可恢復的問題并未有任何幫助。
Spring對于數(shù)據(jù)訪問異常的unchecked使用和許多——可能是大多數(shù)——成功的持久化框架是一致的。（確實，它部分是受到JDO的影響。）JDBC是少數(shù)幾個使用checked exception的數(shù)據(jù)訪問API之一。例如TopLink和JDO大量使用unchecked exception。Gavin King現(xiàn)在相信Hibernate也應該選擇使用unchecked exception。
Spring的JDBC能夠用以下辦法幫助你：
你決不需要在使用JDBC時再編寫finally block。
總的來說你需要編寫的代碼更少了
你再也不需要挖掘你的RDBMS的文檔以找出它為錯誤的列名稱返回的某個罕見的錯誤代碼。你的程序不再依賴于RDBMS特有的錯誤處理代碼。
無論使用的是什么持久化技術(shù)，你都會發(fā)現(xiàn)容易實現(xiàn)DAO模式，讓業(yè)務代碼無需依賴于任何特定的數(shù)據(jù)訪問API。
在實踐中，我們發(fā)現(xiàn)所有這些都確實有助于生產(chǎn)力的提高和更少的bug。我過去常常厭惡編寫JDBC代碼；現(xiàn)在我發(fā)現(xiàn)我能夠集中精力于我要執(zhí)行的SQL，而不是煩雜的JDBC資源管理。
如果需要的話Spring的JDBC抽象可以獨立使用——不強迫你把它們用作Spring的一部分。
posted on 2005-10-26 15:53
Sung 閱讀(339)
評論(0) 編輯 收藏 所屬分類:
Ｊａｖａ