分頁參數處理邏輯的最佳實踐

　　本文講的不是如何結合數據庫實現分頁功能，而是對分頁參數pageNum和pageSize缺省時的處理邏輯。結合工做經驗，談談不一樣方案的優缺點，並推導出最佳方案。

 

參數：pageNum, pageSize

pageNum 指的是拉取第幾頁的數據（也叫記錄，下同），從1開始。
pageSize 指的是每頁多少條數據。特別地，當pageSize=0時，表明拉取所有數據，此時pageNum無心義。

需求：
1. pageNum和pageSize能不傳就儘可能不傳，方便使用。

方案A：
pageNum缺省是1
pageSize缺省是0
因此，當兩個參數都不傳時，天然就是返回所有記錄。

優勢：規則簡單，好理解。
缺點：遇到大表時，開發人員一不當心調用就卡死了。卡死前端，也可能連後端都卡死。
開發人員剛接觸一個新API時，正常的想法是什麼參數都不傳，調用一下看什麼反應。

因此需求改成：
1. pageNum和pageSize能不傳就儘可能不傳，方便使用。
2. 避免不當心返回表的所有記錄。

方案B：
pageNum缺省是1
pageSize缺省是20
因此，當兩個參數都不傳時，就是返回第1頁記錄。
若要返回所有記錄，則必須傳pageSize=0。

優勢：不傳參數時，不管表有多少記錄，不再會出現卡死的狀況了。
缺點：前端不知道某些接口是有分頁的，沒傳分頁參數，某些表（好比管理員表）一開始數據量小沒發現問題，使用一段時間後，超過1頁了，超過的就顯示不出來。這個坑不太容易發現。並且不是一兩個接口有這個問題，工做量不小。生產環境修復Bug，得當心謹慎。

　　因此，不傳分頁參數時，應該如何處理纔是最佳作法（最佳實踐）是個值得三思的問題。

需求再次修改成：
1. pageNum和pageSize能不傳就儘可能不傳，方便使用。
2. 避免不當心返回表的所有記錄。
3. 避免前端不知道分頁機制的存在，沒傳分頁參數，得不到第1頁之外的數據。

分析：
若pageNum和pageSize都空，則不能返回所有記錄，也不能返回第1頁。
既然，不能返回所有，也不能返回第1頁，更不能返回第n頁，那就只能報錯了。

什麼條件下報錯，報什麼錯？
有pageNum，有pageSize，正常執行。
有pageNum，有pageSize，且pageSize=0，正常執行。
無pageNum，有pageSize，且pageSize=0，正常執行。
有pageNum，無pageSize，pageSize取默認值，正常執行。
無pageNum，有pageSize，且pageSize不是0，報錯：pageNum不能空。
無pageNum，無pageSize，報錯：pageNum不能空。

無pageSize，則pageSize是null不是0

方案C：
有pageNum時，若無pageSize，則pageSize設爲20。
無pageNum時，若pageSize不是0，則報錯，錯誤信息：pageNum不能空。

優勢：
1. 有pageNum時，pageSize能夠不傳；pageSize傳0時，pageNum能夠不傳，知足需求第1點。
2. pageNum和pageSize都不傳時報錯，避免了返回所有記錄，知足需求第2點。
3. pageNum和pageSize都不傳時報錯，強迫前端pageNum和pageSize至少傳一個，前端也就知道這個接口有分頁功能，知足需求第3點。

　　方案C就是最佳實踐。我孜孜不倦地追求最佳方案，以不變應萬變。

　　By the way, 關於pageSize默認20，成了業界的不成文規定，好像誰也沒有要打破的意思，對此，我有見解。沒有誰規定一頁的默認記錄數非20不可。鑑於目前互聯網和通訊的發達，我我的推薦一頁默認50條記錄。

當你遇到一個軟件，每次拉取20條記錄，每次拉取都要等待一兩秒，而你想一想拉取500條記錄，操做起來想死的心都有了，你就會以爲每頁20條，是多麼不合理。