系列文章目錄
前言
一、分頁_分析Page分頁的業務和sql
現在的網站基本上都有分頁
我們可以自己動手去查一下,随便浏覽一個有分頁的網站,大部分都是有分頁的
不分頁行不行呢?
1、不分頁使用者體驗很差
如果有300萬條資料,這個下拉條基本上看不見了
2、資料量很大的的時候,伺服器的壓力也是巨大的,甚至直接奔潰卡死
比如上億條資料,背景資料庫要查個幾分鐘,前台就卡死了
分頁必備的元素
然後分析怎麼實作
首先肯定是sql
1、分頁的sql
注意資料庫不同,關鍵字是所有不同的,比如SqlServer是用between,MySQL是用 limit
使用者傳過來的隻是頁碼,其它的我們要自行處理,不能讓使用者去找規律,是以我們必須處理好這個邏輯
如上面的例子
每頁顯示個數是固定的 5(在沒有改動的情況下)
頁碼又是使用者傳過來的
是以變化的就是開始下标,開始下标是可以通過已知條件計算出來的,是有規律的
– 是以實際上 開始的标志 經曆了 0 5 10 15 20 25 ……這樣的變化
– 規律是 啥 (目前頁碼-1)*頁碼大小
– 比如第1頁(1-1)*5,5
– 比如第2頁(2-1)*5,5
– 比如第2頁(3-1)*5,5
到這就可以停一停了,我們可以寫接口了
但是回過頭來我們想一下,分頁,我們隻要有pageNo就可以解決了嗎?
我們寫肯定要比百度寫得要好一些吧,至少給客戶看的東西要多一些,至于使用者看不看那就讓它自己選擇了
&&&不變的的
上一個
下一頁
&&& 變量:
目前頁:使用者傳過來的,最後再展示給使用者就好,就好像使用者點了一碗面,給他是時候告訴他這是您的面
總頁數
總記錄數
每頁顯示多少條資料(可以内部我們設定好,也可以開放出來讓使用者自己設定)
跳轉到目标頁
這5個變量
每點一次下一頁,都要考慮這5個點
是以我們的接口當中需要定義好這5個屬性
但是這5個屬性有點多,難道1一直傳參嗎?5個傳來傳去?
這樣不符合我們的一貫風格
是以我們封裝一個bean,這種bean我們就稱之為業務bean,因為表中,并沒有這個表
是以這裡我們可以知道,bean分為兩種,
一種叫資料bean(資料庫中有這張表)
一種叫業務bean(資料庫中沒有這張表)為了一個業務而去建立的一個bean,我們現在就是為了分頁這個業務
考慮一下page為什麼加泛型呢?
因為泛型更合理
接下來就是代碼實作實作
二、實作Page業務Bean(5個屬性值)
有兩種思路,正常來說我們放bean包裡面,因為它是屬于業務bean
但是如果不好了解的話,我們也可以放util裡面(工具的意思),
這裡的Page.java類,相當于一個分頁工具,因為資料庫裡面并沒有這個表
切記,嚴格來說應該放bean裡面(因為它是業務bean)
注意有兩個地方需要分頁,這兩個地方我們的分頁盡量要統一,因為後端要為前端服務
是以因為有一個是4條資料,是以我們整體都用4條資料為1頁,這樣就不用多寫備援代碼了,
除非有特殊要求再修改
然後構造器、get set 、toString 一套操作
我們想想這樣封裝有什麼好處
“快遞”我們最終是要把它放到域中,這樣就一次全部放了,真好
放也友善,取也友善,相當于打了個包,不會太亂
三、計算總頁數
,這裡需要注意
假如是每頁4條資料,如果我有8條資料肯定是8/4=2頁,這個沒得說,
但是如果我是7條資料是 幾頁呢7/4=1……3 是1頁嗎,不,實際上也是2頁
如果我是5條資料呢…………………………………… …實際上也是2頁
是以我們要用到一個向上取整的函數(C#裡面叫做天花闆函數)
天花闆函數的底層邏輯(如果沒有天花闆函數我們直接if……else也可以實作天花闆函數同樣的功能)
判斷能不能整除,如果能整除,就取整除後的值
如果不能整除,就取整除後的值+1
因為java這裡嗎,沒有提供天花闆函數我們直接使用底層代碼
在bean裡面修改一下getTotalPageNo
直接傳回這個就行了,替換掉原來傳回的值
計算總頁數是傳回getBean還是getBeanList呢?好像都不是
我們發現一個很尴尬的問題,底層沒有提供關于聚合函數的方法給我們調用
是以我們需要自己寫一個
改成ScalarHandler 并且不需要泛型
以後隻要是查詢單個值的傳回結果,我們就可以調用getSingeValue 方法
然後就是dao的接口,dao的接口我們需不需要傳回值呢
然後就是dao的實作類
一個方法裡面寫兩個dao
id是主鍵,有人會認為寫id更靠譜一點
還有些寫1的
1其實不好了解,可以像下面這樣去了解
總記錄數和總頁數就出來了
注意,一定是先有記錄數再會有總頁數,順序不能颠倒
總結
1、下一篇實作分頁
2、一定要寫單元測試,測試一下接口,因為很有可能接口沒通,我們寫半天等于白寫