Spring的開發初衷是為了減輕企業級開發的復雜度，其對數據庫訪問的支持亦如此，使用Spring訪問數據庫能帶來以下好處：

使用原生的JDBC訪問數據庫，一般總是要執行以下步驟：

1) 獲取數據庫資源，例如連接等；

2) 準備并執行SQL，并處理返回結果

3) 釋放數據庫資源

4) 處理上述所有步驟出現的異常，處理異常的過程中也要捕獲異常

典型的代碼結構如下：

public TestObj queryTestObj(long id)

{

final String SQL_SELECT_OBJ="select * from testobj where id=?";

Connection conn = null;

PreparedStatement stmt = null;

ResultSet rs=null;

try

{

conn = dataSource.getConnection();

stmt = conn.prepareStatement(SQL_SELECT_OBJ);

stmt.setLong(1, id);

rs = stmt.executeQuery();

TestObj obj=null;

if(rs.next())

{

obj = new TestObj();

//將查詢出的各項屬性設置至TestObj對象

}

return obj;

}

catch(SQLException ex)

{

//處理異常

}

finally

{

if(rs!=null)

{

try

{

rs.close();

}

catch(SQLException ex)

{

}

}

if(stmt!=null)

{

try

{

stmt.close();

}

catch(SQLException ex)

{

}

}

if(conn!=null)

{

try

{

conn.close();

}

catch(SQLException ex)

{

}

}

}

return null;

}

從示例代碼可以看出，真正與業務相關的部分僅僅占用代碼的不到20%，而其他大部分代碼都在做一些與業務無關的事情，但是這些“冗余代碼”卻是必不可少而且每個數據庫處理都需要，根據“職責拆分”的原則，解決這個問題的辦法很明顯：將這些“冗余代碼”集中到一起。“大步驟相同，而部分步驟的處理細節不同”，這是“模板模式”的典型應用場景。

Spring已經為我們做好了。

先看示例，使用Spring提供的JDBC模板后，上述代碼會變成這樣：

public TestObj queryTestObjBySping(long id)

{

final String SQL_SELECT_OBJ="select * from testobj where id=?";

return jdbcTemplate.queryForObject(SQL_SELECT_OBJ,

new ParameterizedRowMapper<TestObj>()

{

@Override

public TestObj mapRow(ResultSet arg0, int arg1)

throws SQLException

{

TestObj obj = new TestObj();

//將查詢出的各項屬性設置至TestObj對象

return obj;

}

}, id);

}

原生JDBC的數據庫操作異常類包括BatchUpdateException、DataTruncation、SQLException、SQLWarning四個，而令人難以理解的是，這些異常都是Checked異常，也就是說，代碼中必須顯式捕捉它們，但是如果出現這些異常，一般都是發生了致命性的且運行時不可恢復的錯誤，異常處理塊中除了打印堆棧外難以有其他有意義的操作。

Spring對此做了兩個改進：（1）細化異常，便于分析問題；（2）將異常修改為UnChecked類型。

Spring細化的異常如下