Web開發之分頁演算法，N(N>=3)種解決方案
阿新 • • 發佈：2019-01-05
1. 定義問題
原由：在頁面中需要展示若干資料，但不可能一次展示所有的，想通過每次只展示若干條。分頁數，pageNo，是為了標記，當前訪問的內容在哪裡。
後端需要做的：後端需要分頁查詢資料，把資料返回給前端
前端需要做的：根據後端的資料，構造“1、2、3”等分頁面板，並且要響應事件，比如點選“2”，就跳轉到第2頁
2. 2種思路
解決方法有很多種，我只想根據幾個指標，列出幾種典型的解決方法。
2.1分頁所有相關邏輯，全部由“後端實現”
a. 獲取資料庫中的資料
根據totalPage（需要先查詢一次資料庫）和pageSize，計算總共有多少也totalPage。
然後生成前端js分頁，前端直接顯示分頁js程式碼${pagejs}。
點選前端分頁連結時，後端再根據當前頁數pageNo和每頁顯示的條數pageSize，獲取資料。
預設顯示第1頁。
注：這種全部由後端生成分頁的方法，我見過，不過，我不喜歡這種做法。由後端生成前端分頁js，感覺太彆扭了。
我的觀點：前端負責前端的事，後端負責後端的事，儘量不互相影響。
2.2後端只負責資料查詢，前端負責構造分頁js。
後端計算count，獲取一頁資料list。如果用Mybatis，可以寫一個攔截器，或者工具方法，自動去查詢count。因為count的sql可以根據list的sql來構造，所以能自動化。
前端根據分頁完整資訊page，構造js。
3.同步or非同步
前端的分頁，可以選擇“同步重新整理“，每次開啟新的頁面（可能直接覆蓋當前頁，讓人看起來沒有重新重新整理頁面）。
也可以選擇“非同步重新整理”，傳送AJAX請求，替換分頁內容。
不同點在於，同步重新整理，需要構造“URL”，URL帶上了分頁資訊pageNo，pageSize,也可能需要帶上各種查詢引數，比如使用者名稱username.
非同步重新整理，需要給分頁“1”繫結事件響應函式，分頁元件需要把這個“回撥函式”，提取出來，可以由分頁呼叫者傳入。另外一點，分頁元件會自動記住查詢引數和分頁資訊。這一點，比同步構造url要簡單一些。
4.表格型or內容型
分頁展示的內容可能是表格型，比如“uid uname time money”，一個使用者的資金記錄，也可能是一頁內容，比如一篇文章下方展示10條評論。
表格型的佈局展示相對更加“標準化” ，而內容型則變化較大，通常需要自己去構造。
或者，對錶格型的元件進行改進，把“渲染一行內容” 提取成函式，可以讓呼叫者自己傳入“渲染方法”，從而達到“複用”的目的。
5.我的實踐與選擇
a.前端與後端分離，後端查詢資料，前端負責展示資料，後端不會生成前端需要的js和html等內容。
b.表格型-非同步
參考秒針前同事寫的st-grid，即網上最流行的標準化表格型grid分頁元件。
或者從網上找，比如jquery等各種整套前端框架，都會有這個元件
c.表格型-同步
前端用JSTL、Freemarker、Struts標籤、JSP標籤等模版技術，生成分頁條，表格內容寫個for迴圈。
這個地方的分頁條，也可以用JS來實現，不過麻煩一點。
同步型的，需要在URL中帶上各種分頁引數和查詢條件，想做成通用的，有一定難度。
d.內容型-非同步
後端都一樣，前端寫AJAX方法，構造html，再渲染。
這個是我在寫個人官網時，遇到的“新場景”，全部程式碼，都由我根據其它方式的程式碼，改造而來。
顯示1篇文章，下方顯示若干評論，點選下一頁，評論重新整理，文章不重新整理。
e.內容型-同步
與“表格型-同步” 類似，唯一不同的是，for迴圈生成的不是table，而是div，佈局更好看。
6.扯點別的
程式碼，我就不貼了，排版很麻煩，而且程式碼一大堆。這麼多種場景，每一種場景的實際程式碼，都不少。有機會，今後再詳細闡述。
通過分頁這個事，我再次發現，技術的一個難點就在於，實際的業務或需求有很多種場景，不同場景下的技術實現思路是不同的。想“一次編寫，處處使用”非常難。可行的方法是，“一種場景，儘量只編寫一次程式碼，保證這個場景下是萬能的就很厲害了”。
寫完這篇文章，我猛然發現，可能以前就發現了，在某些領域，我比很多“高階工程師”都要厲害。為什麼呢？每個技術工作者在實際工作中遇到的問題是不同的，“術業有專攻”，每個人都在自己的興趣和工作範圍內的事情更為擅長。
今天就扯到這吧，更多關於“技術觀點” 的，將放在“雷觀”中詳細闡述。
總之，我比2年前，剛剛畢業的時候，要強太多了。青春流逝了，我也成長了。
小雷FansUnion-博學的網際網路技術工作者
個人官網：http://FansUnion.cn
2014年12月6日