接手一個老項目打開代碼庫第一眼最容易讓人崩潰的永遠是數(shù)據(jù)訪問這一層。幾百個類、上千行SQL有的直接用字符串拼有的用預編譯有的返回List有的返回Map還有個別方法把ResultSet直接甩給上層業(yè)務(wù)代碼讓Servlet層自己去遍歷游標。這不是編出來的極端案例見過類似的代碼越多越覺得很多人不是不會寫數(shù)據(jù)庫訪問而是從入行開始就沒人告訴他一套統(tǒng)一的約束應(yīng)該長什么樣。今天要聊的JDBC數(shù)據(jù)庫訪問與DAO設(shè)計模式本質(zhì)就是解決這個問題的。它能讓你把數(shù)據(jù)庫的存取細節(jié)封裝在固定的一層里業(yè)務(wù)代碼不用再關(guān)心那些Connection、ResultSet、SQLException也能讓一個團隊寫出來的數(shù)據(jù)訪問代碼長成一個樣子可讀、可測、可替換。1. 為什么數(shù)據(jù)庫訪問層總成為項目的黑洞1.1 一段真實到有點尷尬的失控代碼先把最容易踩的坑擺出來。很多老項目里都能看到這類代碼看起來只是幾句普通的數(shù)據(jù)庫操作實際上處處是雷Class.forName(com.example.jdbc.Driver); Connection conn DriverManager.getConnection( jdbc:你的廠商標識://127.0.0.1:你的端口/demo, 你的用戶名, 你的密碼); Statement stmt conn.createStatement(); ResultSet rs stmt.executeQuery( SELECT * FROM t_user WHERE name name ); while (rs.next()) { // 手工取值、手工拼對象 } conn.close();這段代碼第一次跑通的時候很爽可它隱藏了至少四個問題第一用戶輸入直接拼進SQL等于把語句結(jié)構(gòu)暴露給了外部輸入一旦有人傳入帶有攻擊性質(zhì)的片段整個表的數(shù)據(jù)都可能被拖走第二try-catch里如果只打了異常棧卻沒有在finally中關(guān)閉連接查詢一報錯連接就永久泄漏第三Statement每次執(zhí)行都要讓數(shù)據(jù)庫重新解析一遍SQL在高頻訪問下白白浪費數(shù)據(jù)庫的解析時間第四ResultSet被直接暴露給上層以后業(yè)務(wù)代碼不得不了解JDBC的游標機制改字段、換數(shù)據(jù)結(jié)構(gòu)時牽一發(fā)而動全身。1.2 失控的根因不是能力而是缺少邊界我復盤過很多次這類問題結(jié)論是寫壞代碼的人不一定水平差而是JDBC這套API給了太大的自由。JDBC本身是一個能力非常完整的接口標準但它把決定權(quán)完全交給了調(diào)用者。連接要不要復用字段怎么映射異常怎么處理事務(wù)邊界劃在哪里這些在API層面沒有強制約束也沒有統(tǒng)一的默認規(guī)范于是十個人就能寫出十種數(shù)據(jù)訪問風格。業(yè)務(wù)少的時候風格差異還看不出來等表多了、方法多了、團隊大了壞味道會隨著業(yè)務(wù)量一起放大。一個查詢從Service層拼SQL拼到DAO層人手一份ResultSet遍歷模板改一個公共字段要在幾十個類里搜索替換。這時候你真正缺的不是某個新的數(shù)據(jù)庫框架而是一層約定的邊界。DAO設(shè)計模式就是這條邊界它把“怎么存取數(shù)據(jù)”這件事的所有細節(jié)關(guān)在一個籠子里業(yè)務(wù)層只和籠子外面那張穩(wěn)定接口打交道。2. JDBC是接口標準不是某個具體實現(xiàn)2.1 驅(qū)動JAR才是真正干活的人很多人把JDBC當成一個具體的庫其實它是Java平臺上訪問數(shù)據(jù)庫的一組接口標準定義在java.sql包里。真正實現(xiàn)這些接口的是數(shù)據(jù)庫廠商提供的驅(qū)動JAR。你換一種數(shù)據(jù)庫只要換掉驅(qū)動JAR和連接URL業(yè)務(wù)代碼里用到的Connection、PreparedStatement、ResultSet這些類名統(tǒng)統(tǒng)不用變。這就是接口標準的威力上層面對統(tǒng)一抽象底層負責各自方言。驅(qū)動加載通常通過Class.forName(驅(qū)動類全限定名)完成在新一點的JDBC版本里驅(qū)動JAR通過ServiceLoader機制自動注冊這句有時可以省略。但為了兼容老環(huán)境我還是習慣在連接工具類的靜態(tài)代碼塊里顯式加載一次花不了幾個字符能省掉不少詭異的環(huán)境問題。2.2 Connection、Statement、ResultSet各自扮演什么角色用一個電話類比來理解這三個核心接口會非常直觀Connection就是一條撥通的電話線路代表與數(shù)據(jù)庫的一次會話線路要在通話結(jié)束后掛斷。Statement是你在電話里說出去的一句話。PreparedStatement更特殊它像一張預先寫好底稿、只留出空檔往里面填內(nèi)容的臺詞好處是數(shù)據(jù)庫先解析框架后面每次只要填參數(shù)就行。ResultSet是電話那頭一句一句返回的答復。它內(nèi)部維護著一個游標初始位置在第一行之前調(diào)用next()才會向下移動移動到哪一行那一行的數(shù)據(jù)才可讀讀完之后游標不會自動回到開頭。這三個接口加一個DriverManager就是JDBC最小可用的全部骨架。理解了它們你后面看任何持久層框架的源碼都不會覺得陌生因為無論外面包了多少層薄紗核心仍然是這套東西。2.3 一次完整查詢的底層生命周期把一次最普通的查詢拆開看它的完整路徑是這樣的// 1. 獲取連接這一步可能來自DriverManager也可能來自連接池 Connection conn DBUtil.getConnection(); // 2. 預編譯SQL數(shù)據(jù)庫端先解析結(jié)構(gòu)?是參數(shù)占位符 PreparedStatement ps conn.prepareStatement( SELECT id, name, age FROM t_user WHERE name ?); // 3. 綁定參數(shù)參數(shù)只作為數(shù)據(jù)傳給數(shù)據(jù)庫不參與SQL結(jié)構(gòu)拼接 ps.setString(1, userName); // 4. 執(zhí)行查詢返回結(jié)果集游標 ResultSet rs ps.executeQuery(); // 5. 游標逐行移動每一行通過RowMapper轉(zhuǎn)換成業(yè)務(wù)對象 while (rs.next()) { User user new User(); user.setId(rs.getLong(id)); user.setName(rs.getString(name)); // 這里每換一張表都要重新寫一遍模板 } // 6. 釋放資源順序是ResultSet - Statement - Connection rs.close(); ps.close(); conn.close();你會發(fā)現(xiàn)第2步和第3步的組合已經(jīng)優(yōu)于Statement拼字符串SQL結(jié)構(gòu)在數(shù)據(jù)庫端被鎖定參數(shù)永遠只是參數(shù)這是防注入的根本原因。但更刺眼的還是第5步——每張表、每個查詢都要重復寫“游標移動、按列名取值、set進對象”的模板代碼而且要小心翼翼保證第6步在異常路徑上也能執(zhí)行到。如果不幸漏了一行close連接就會被一直占著數(shù)據(jù)庫的連接數(shù)很快被吃光。這也是為什么原生JDBC“能用但不好用”痛點非常具體。3. 原生JDBC為什么“能用但不好用”裂縫在哪3.1 連接獲取是一次昂貴的“重會話”每次調(diào)用DriverManager.getConnection都會讓數(shù)據(jù)庫重新完成一次網(wǎng)絡(luò)握手、身份認證、會話資源分配。想象一下你每說一句話都要重新?lián)芤淮坞娫?、等對方接聽、寒暄兩句才進入正題這顯然不可持續(xù)。在高并發(fā)場景下頻繁創(chuàng)建連接會讓數(shù)據(jù)庫端線程調(diào)度壓力暴增更嚴重的是如果應(yīng)用層沒有及時關(guān)閉連接連接數(shù)會一直漲直到數(shù)據(jù)庫拒絕新的會話。解決連接復用問題的手段是連接池但連接池不是JDBC之外的東西它只是實現(xiàn)了DataSource接口對外仍然返回Connection對象。換連接池的時候上層取連接的寫法甚至不用變DriverManager.getConnection換成dataSource.getConnection而已。DAO層如果從一開始就面對DataSource而不是DriverManager后面做連接池更換幾乎零成本。3.2 樣板代碼累積起來就是技術(shù)債說句實話JDBC里最讓人頭疼的不是API難懂而是重復。每個方法都要經(jīng)歷“拿連接、建語句、設(shè)參數(shù)、執(zhí)行、映射結(jié)果、關(guān)資源”這條流水線而且每個環(huán)節(jié)還都可能出錯。有人試過用try-with-resources簡化釋放邏輯但一旦連接來自連接池close()的語義變成了歸還連接而不是真正關(guān)閉很多人在這里會愣一下。更隱蔽的是異常處理。很多項目的DAO方法里只有空catch日志里什么都看不到數(shù)據(jù)庫報錯就像被黑洞吞掉。等線上出問題你連是哪條SQL失敗都查不出來。這些樣板代碼帶來的不是單點故障而是集體性的可維護性惡化。3.3 SQL和業(yè)務(wù)邏輯糾纏不清的連鎖反應(yīng)原生JDBC沒有強制數(shù)據(jù)訪問層的位置于是SQL經(jīng)常直接出現(xiàn)在Servlet、Service甚至工具類里。最直接的問題是SQL里的字段名寫錯、表名寫錯編譯期完全察覺只有運行到那一行才知道。數(shù)據(jù)庫改個字段名你要在整個項目里搜索字符串一個查詢被復用了三次值被改了一處另外兩處還跑在老邏輯上。我把這些痛點整理成一張表方便你對號入座原生JDBC的痛點典型后果連接頻繁創(chuàng)建銷毀高并發(fā)下連接耗盡、性能抖動SQL散落在業(yè)務(wù)代碼改表結(jié)構(gòu)要全局搜索漏改一處就出錯手寫結(jié)果集映射大量重復模板代碼空值、列缺失難發(fā)現(xiàn)異常處理隨意關(guān)鍵錯誤被吞掉線上排查無從下手事務(wù)邊界混亂跨多表操作部分成功、部分失敗數(shù)據(jù)不一致4. DAO設(shè)計模式的核心思想把存取細節(jié)關(guān)進籠子4.1 單一職責與依賴倒置DAO到底在保護誰DAO的全稱是Data Access Object數(shù)據(jù)訪問對象。它的核心思想其實就一句話把數(shù)據(jù)存取的全部細節(jié)關(guān)在這一層其他層不允許碰數(shù)據(jù)庫API。這樣做有兩個層面的保護。物理層面連接獲取、SQL執(zhí)行、結(jié)果集映射、資源釋放全都在DAO實現(xiàn)類內(nèi)部完成業(yè)務(wù)層看不到任何Connection和ResultSet。邏輯層面業(yè)務(wù)層只依賴DAO接口不依賴具體實現(xiàn)。依賴倒置的好處立刻顯現(xiàn)測試的時候可以替換成內(nèi)存樁實現(xiàn)數(shù)據(jù)庫遷移時只改DAO實現(xiàn)類上層業(yè)務(wù)一行不動。4.2 一個標準DAO族的組成與分工一個規(guī)范的DAO族通常由四部分組成實體類也叫PO或DO一張表對應(yīng)一個Java類字段與表字段保持映射關(guān)系。DAO接口定義這張表所有對外可用的操作方法簽名里不出現(xiàn)SQL和JDBC類型。DAO實現(xiàn)類真正寫SQL、操作JDBC的地方也是全文唯一允許出現(xiàn)SQL片段的位置。連接工具類或數(shù)據(jù)源給所有實現(xiàn)類提供統(tǒng)一的連接獲取和資源釋放入口。比如用戶表的接口可以長這樣public interface UserDao { User findById(Long id); User findByName(String name); ListUser findByAgeRange(int minAge, int maxAge); Long insert(User user); int update(User user); int delete(Long id); }實現(xiàn)類里要做什么就很明確了把findById翻譯成一條SELECT把insert翻譯成一條INSERT同時保證用完的資源被正常釋放。業(yè)務(wù)層看到的是“查用戶”“新增用戶”這樣業(yè)務(wù)化的語義而不是“打開連接、拼SQL、遍歷游標”這樣的技術(shù)步驟?？赡苡腥藭栃№椖渴遣皇强梢圆粚懡涌谥苯佑靡粋€類搞定我的經(jīng)驗是如果有測試需求或者預期這張表的存儲方式未來可能變化接口帶來的收益就很大。哪怕目前只有一種實現(xiàn)“接口 實現(xiàn)類”這個結(jié)構(gòu)本身也在提醒你這條邊界是存在的不能越過它去訪問數(shù)據(jù)庫。5. 手把手搭一套可復用的DAO基礎(chǔ)設(shè)施5.1 先用DBUtil把連接的獲取和釋放統(tǒng)一起來DAO層最底下的地基是一個連接工具類。它負責兩件事提供連接以及安全地釋放資源。下面是一個簡化版的樣子public final class DBUtil { private static DataSource dataSource; private DBUtil() { } // 實際項目中這里通過配置文件初始化數(shù)據(jù)源 // 比如讀取配置后創(chuàng)建連接池實例這里用占位示意 public static void init(DataSource ds) { dataSource ds; } public static Connection getConnection() throws SQLException { if (dataSource null) { throw new IllegalStateException(數(shù)據(jù)源尚未初始化); } return dataSource.getConnection(); } public static void close(ResultSet rs, Statement stmt, Connection conn) { if (rs ! null) { try { rs.close(); } catch (SQLException ignored) { } } if (stmt ! null) { try { stmt.close(); } catch (SQLException ignored) { } } if (conn ! null) { try { conn.close(); } catch (SQLException ignored) { } } } }注意幾點。第一關(guān)閉順序一定是ResultSet先、Statement其次、Connection最后雖然現(xiàn)代JDBC驅(qū)動在關(guān)閉Statement時通常會連帶關(guān)閉ResultSet但顯式關(guān)閉能讓日志和監(jiān)控更清楚。第二當連接來自連接池時close()不是真正斷開而是把連接歸還給連接池復用。第三異常即使想忽略也建議打一條trace級日志完全不理會讓連接泄漏問題無法追蹤。5.2 泛型BaseDao把查詢模板和結(jié)果映射分開有了連接工具類下一步是消滅重復的模板代碼。核心思路是用一個泛型基類把“執(zhí)行查詢、遍歷游標、關(guān)閉資源”這些公共流程抽出來把“每行怎么轉(zhuǎn)成對象”留給調(diào)用方通過回調(diào)傳入。這個回調(diào)就是常說的RowMapper。先定義一個函數(shù)式接口FunctionalInterface public interface RowMapperT { T mapRow(ResultSet rs, int rowNum) throws SQLException; }再寫一個泛型基類public abstract class BaseDaoT { protected ListT queryForList(String sql, RowMapperT rowMapper, Object... params) throws SQLException { Connection conn null; PreparedStatement ps null; ResultSet rs null; try { conn DBUtil.getConnection(); ps conn.prepareStatement(sql); setParameters(ps, params); rs ps.executeQuery(); ListT result new ArrayList(); int rowNum 0; while (rs.next()) { result.add(rowMapper.mapRow(rs, rowNum)); } return result; } finally { DBUtil.close(rs, ps, conn); } } protected T queryForObject(String sql, RowMapperT rowMapper, Object... params) throws SQLException { ListT list queryForList(sql, rowMapper, params); if (list null || list.isEmpty()) { return null; } return list.get(0); } protected int update(String sql, Object... params) throws SQLException { Connection conn null; PreparedStatement ps null; try { conn DBUtil.getConnection(); ps conn.prepareStatement(sql); setParameters(ps, params); return ps.executeUpdate(); } finally { DBUtil.close(null, ps, conn); } } protected Long insertReturnKey(String sql, Object... params) throws SQLException { Connection conn null; PreparedStatement ps null; ResultSet rs null; try { conn DBUtil.getConnection(); ps conn.prepareStatement(sql, Statement.RETURN_GENERATED_KEYS); setParameters(ps, params); ps.executeUpdate(); rs ps.getGeneratedKeys(); if (rs.next()) { return rs.getLong(1); } return null; } finally { DBUtil.close(rs, ps, conn); } } private void setParameters(PreparedStatement ps, Object... params) throws SQLException { if (params null) { return; } for (int i 0; i params.length; i) { ps.setObject(i 1, params[i]); } } }這個基類一出來80%的樣板代碼就消失了。queryForList負責搞定“連接、預編譯、綁定參數(shù)、遍歷游標、關(guān)閉資源”調(diào)用方只需要關(guān)心兩件事SQL里占位符的順序以及RowMapper里一行數(shù)據(jù)怎么變成對象。insertReturnKey特別注意一下它通過Statement.RETURN_GENERATED_KEYS讓數(shù)據(jù)庫返回自增主鍵避免插入之后還要再查一次。5.3 落地一個真實的UserDao有了BaseDao之后寫UserDao的實現(xiàn)類會變得非常輕快public class UserDaoImpl extends BaseDaoUser implements UserDao { Override public User findById(Long id) { String sql SELECT id, name, age, create_time FROM t_user WHERE id ?; return queryForObject(sql, (rs, rowNum) - toUser(rs), id); } Override public User findByName(String name) { String sql SELECT id, name, age, create_time FROM t_user WHERE name ?; return queryForObject(sql, (rs, rowNum) - toUser(rs), name); } Override public ListUser findByAgeRange(int minAge, int maxAge) { String sql SELECT id, name, age, create_time FROM t_user WHERE age BETWEEN ? AND ?; return queryForList(sql, (rs, rowNum) - toUser(rs), minAge, maxAge); } Override public Long insert(User user) { String sql INSERT INTO t_user(name, age, create_time) VALUES (?, ?, ?); return insertReturnKey(sql, user.getName(), user.getAge(), user.getCreateTime()); } Override public int update(User user) { String sql UPDATE t_user SET name ?, age ? WHERE id ?; return update(sql, user.getName(), user.getAge(), user.getId()); } Override public int delete(Long id) { String sql DELETE FROM t_user WHERE id ?; return update(sql, id); } private User toUser(ResultSet rs) throws SQLException { User user new User(); user.setId(rs.getLong(id)); user.setName(rs.getString(name)); user.setAge(rs.getInt(age)); user.setCreateTime(rs.getTimestamp(create_time)); return user; } }這段代碼讀起來順眼多了。每個方法一眼就能看出在做什么SQL只有這一層有參數(shù)按順序填資源統(tǒng)一由基類釋放RowMapper把數(shù)據(jù)庫行轉(zhuǎn)換成業(yè)務(wù)對象。業(yè)務(wù)層調(diào)用時只需要拿到UserDao接口不用知道背后有BaseDao、有DBUtil這些東西。6. 規(guī)?；飞系娜竭B接池、事務(wù)邊界、批量與分頁6.1 連接池只是換了連接來源DAO接口紋絲不動數(shù)據(jù)庫連接池的標準做法是通過DataSource對外提供連接。你只需要在項目啟動時初始化一次連接池實例再把它交給DBUtil.init。連接池的核心參數(shù)有這些參數(shù)名稱含義備注初始連接數(shù)啟動時就創(chuàng)建好的連接數(shù)量啟動較慢但第一波請求更穩(wěn)最大活動連接數(shù)同時最多能分配的連接數(shù)量設(shè)置太小會排隊太大浪費資源最小空閑連接數(shù)長期保持的空閑連接數(shù)量與最大活動數(shù)配合控制回收最大等待時間請求連接排隊超過此時長則報錯單位毫秒避免請求無限等待連接校驗查詢?nèi)〕鲞B接前檢查是否可用常見寫法是執(zhí)行一條輕量查詢一旦連接池接入DBUtil.getConnection()內(nèi)部返回的就是池里分配的連接close()變成歸還連接。DAO接口本身完全不動ServiceImpl也不動這就是前面強調(diào)封裝的價值——底層存儲來源怎么換上層用起來沒有任何感知。6.2 事務(wù)邊界歸Service層連接傳遞用ThreadLocal連接池解決的是連接復用可它管不了事務(wù)。一個業(yè)務(wù)方法往往要調(diào)用多個DAO方法比如轉(zhuǎn)賬要“扣A賬戶”和“加B賬戶”這兩個操作必須在同一個數(shù)據(jù)庫連接上完成、要么一起成功、要么一起回滾。如果每個DAO方法都自己拿連接、自己提交就會出現(xiàn)A扣款成功但B加款失敗的尷尬局面。業(yè)界比較通用的方案是事務(wù)邊界劃在Service層DAO層不做提交和回滾事務(wù)所需的連接通過ThreadLocal綁定在當前線程上。偽代碼如下public class ConnectionHolder { private static final ThreadLocalConnection HOLDER new ThreadLocal(); public static void bind(Connection conn) { HOLDER.set(conn); } public static Connection get() { return HOLDER.get(); } public static void unbind() { HOLDER.remove(); } }Service層的典型寫法是public void transfer(Long fromId, Long toId, BigDecimal amount) { Connection conn DBUtil.getConnection(); boolean oldAutoCommit; try { oldAutoCommit conn.getAutoCommit(); conn.setAutoCommit(false); ConnectionHolder.bind(conn); accountDao.decrease(fromId, amount); accountDao.increase(toId, amount); conn.commit(); } catch (Exception e) { conn.rollback(); throw new RuntimeException(轉(zhuǎn)賬失敗, e); } finally { conn.setAutoCommit(true); ConnectionHolder.unbind(); conn.close(); } }對應(yīng)的DAO實現(xiàn)里取連接時先看ConnectionHolder有沒有綁定有就用綁定的沒有再新取Connection conn ConnectionHolder.get() ! null ? ConnectionHolder.get() : DBUtil.getConnection();要點在于DAO層的update方法絕不自己commit或rollback提交時機完全由Service層決定。這樣事務(wù)的粒度才夠大跨多表操作才能保持一致性。6.3 批量寫入與分頁查詢的注意點批量插入如果要一條條執(zhí)行數(shù)據(jù)庫往返次數(shù)多到讓人心疼。JDBC提供了一套批量接口把命令攢到一定數(shù)量再一次發(fā)送String sql INSERT INTO t_order(user_id, amount) VALUES (?, ?); try (Connection conn DBUtil.getConnection(); PreparedStatement ps conn.prepareStatement(sql)) { for (Order order : orderList) { ps.setLong(1, order.getUserId()); ps.setBigDecimal(2, order.getAmount()); ps.addBatch(); if (batchCount % 500 0) { ps.executeBatch(); } } ps.executeBatch(); }分頁查詢則是另一個容易埋坑的地方。最粗暴的寫法是SELECT * FROM t_user然后把所有數(shù)據(jù)load進內(nèi)存再在Java里分頁數(shù)據(jù)量一大內(nèi)存就被打爆。正確做法是讓數(shù)據(jù)庫只返回當前頁需要的那幾行但不同數(shù)據(jù)庫分頁方言不同正好可以由DAO實現(xiàn)類把這種差異消化掉對外部接口完全透明。7. 實戰(zhàn)中我踩過的深坑與排查要點7.1 ResultSet是一條會過期的游標不是結(jié)果集合新手最容易犯的錯誤是把ResultSet當成普通集合返回給上層// 錯誤示范DAO方法返回ResultSet public ResultSet queryByName(String name) { Statement stmt conn.createStatement(); return stmt.executeQuery(SELECT * FROM t_user WHERE name name ); }危險在于ResultSet默認綁定在Statement上Statement關(guān)閉后游標就失效了。等你把ResultSet交到Service層連接可能已經(jīng)關(guān)閉要么報“ResultSet closed”要么拿到一堆看不出時機的怪異異常。正確做法就是在DAO方法內(nèi)部完成映射把數(shù)據(jù)轉(zhuǎn)換成實體對象或DTO列表然后返回普通Java集合。一句話游標不過DAO的邊界。7.2 預編譯與參數(shù)綁定的真正價值參數(shù)是數(shù)據(jù)不是語句結(jié)構(gòu)SQL注入的本質(zhì)是把外部輸入?yún)?shù)當成了SQL語句的一部分去解析。很多書本說“用了PreparedStatement就能防注入”但沒有把為什么講透。關(guān)鍵在兩點一是prepareStatement時數(shù)據(jù)庫已經(jīng)完成了SQL結(jié)構(gòu)解析結(jié)構(gòu)被鎖定二是setXxx綁定參數(shù)時參數(shù)永遠以數(shù)據(jù)的形式傳給數(shù)據(jù)庫不會重新參與結(jié)構(gòu)拼接。所以我在DAO層立了一條死規(guī)矩所有SQL一律用?占位符加預編譯任何情況下不允許用字符串拼接參數(shù)。哪怕參數(shù)看起來非常“安全”比如一個整數(shù)ID也堅持走占位符。習慣一旦養(yǎng)成就不會在某個緊急修復時手滑拼出一個漏洞。7.3 空值、時間類型與自增主鍵的三個細節(jié)結(jié)果集映射里最容易翻車的是空值。getInt(age)在數(shù)據(jù)庫值為NULL時返回0你以為用戶年齡是0其實人家年齡壓根沒填。如果業(yè)務(wù)里需要區(qū)分“沒填”和“填了0”就要用包裝類型// 最好用Integer接收null和0能區(qū)分開 Integer age rs.getObject(age, Integer.class);時間類型也是個經(jīng)典坑。數(shù)據(jù)庫的DATETIME、TIMESTAMP映射到Java通常是java.sql.Timestamp而業(yè)務(wù)里常用java.util.Date。取值時直接rs.getObject(create_time, Timestamp.class)再把Timestamp轉(zhuǎn)成Date千萬別把Timestamp和Date混著用Date持有的毫秒數(shù)對不上會出各種詭異偏差。自增主鍵回填我上面已經(jīng)寫了insertReturnKey這里補充一句判斷邏輯主鍵列必須是數(shù)據(jù)庫自增列且prepareStatement時傳了RETURN_GENERATED_KEYS這樣getGeneratedKeys()才有值。有些JDBC驅(qū)動對“返回主鍵”的支持不太一樣實測時如果拿不到檢查一下表和驅(qū)動兩邊的配置。7.4 排查問題時的習慣把最終SQL和參數(shù)打出來一個讓我少熬好幾次夜的調(diào)試習慣是在DAO基類里把SQL主體和參數(shù)數(shù)組一起打成日志if (log.isDebugEnabled()) { log.debug(SQL: {}, params: {}, sql, Arrays.toString(params)); }這樣線上搜索日志時直接按方法名或表名就能定位到某條請求實際執(zhí)行的SQL是什么、參數(shù)是什么不需要一行行看代碼猜。很多人排查慢查詢時跑到數(shù)據(jù)庫那邊抓SQL卻沒有應(yīng)用側(cè)參數(shù)兩邊對不上白白折騰半天。先在DAO層把上下文信息打印全比什么工具都好使。8. 吃過虧之后我給自己定的幾條DAO規(guī)矩這幾條規(guī)矩是我在幾個項目里踩坑踩出來的不復雜但每一條都對應(yīng)過真實事故。所有SQL只出現(xiàn)在DAO實現(xiàn)類里業(yè)務(wù)層不出現(xiàn)任何SQL片段。每張表對應(yīng)一個DAO一個方法只做一件事。不要搞一個萬能方法接收一堆開關(guān)參數(shù)。連接、Statement、ResultSet統(tǒng)一走工具類關(guān)閉不允許在DAO實現(xiàn)類里散裝管理資源。參數(shù)綁定一律使用?占位符加預編譯永遠不做字符串拼接。事務(wù)入口放在Service層DAO層不主動提交、不主動回滾。結(jié)果集必須在DAO方法內(nèi)部轉(zhuǎn)換成實體或DTO絕不返回游標對象。關(guān)鍵SQL和執(zhí)行參數(shù)要打日志線上敢查、查得到比事后猜強一百倍。如果你現(xiàn)在的項目正處于“SQL滿天飛、改表結(jié)構(gòu)要滿項目搜索”的階段我的建議是先別急著換重型框架。把DAO這一層梳理清楚劃定邊界、統(tǒng)一模板、規(guī)范事務(wù)和連接管理成本最低收益卻立竿見影。等以后再接觸那些主流的持久層框架你會發(fā)現(xiàn)自己早就理解了它們想解決的核心問題。JDBC這套底層接口沒有過時DAO這種設(shè)計思想也沒有過時它們?nèi)匀皇抢斫釰ava數(shù)據(jù)訪問世界的最牢固的地基。