寫過很多項(xiàng)目，主要是基于SHH或者單獨(dú)的Hibernate項(xiàng)目，并提供restful服務(wù)，對(duì)于分頁也做過很多種嘗試：服務(wù)接口直接接受pageNum和pageIndex兩個(gè)參數(shù)，然后返回一個(gè)list；并且提供另外一個(gè)服務(wù)，獲取相同參數(shù)情況下，所有的數(shù)據(jù)的總數(shù)，總頁數(shù)等信息?！緝?yōu)點(diǎn)是，數(shù)據(jù)和分頁信息的分離。讓顯示頁面的部分只關(guān)心數(shù)據(jù)本身。而讓頁碼標(biāo)去管理頁碼信息。缺點(diǎn)是調(diào)用了兩次web服務(wù)?！繉⒎猪撔畔⑴c數(shù)據(jù)封裝在一起，調(diào)用一次web服務(wù)來獲得所有的分頁信息。【優(yōu)點(diǎn)是，一次服務(wù)調(diào)用。單使整個(gè)調(diào)用過程緊耦合了起來，服務(wù)必須是分頁的，返回的數(shù)據(jù)和分頁內(nèi)容放在了一起作為返回值?！?
1 回答
至尊寶的傳說
TA貢獻(xiàn)1789條經(jīng)驗(yàn) 獲得超10個(gè)贊
其實(shí)這涉及到一個(gè)用戶體驗(yàn)的問題(盡管我也不大明白神馬叫用戶體驗(yàn))。現(xiàn)在一般提供的分頁有以下前兩種方式。
1、第一種像你所說的，告訴總的頁數(shù)，以及每頁固定的記錄數(shù)。這種方式下有一個(gè)問題：有時(shí)候用戶其實(shí)根本不關(guān)心你總共有多少條記錄，她只是想隨便看看，而且一般只瀏覽個(gè)前幾十條就差不多了。但是這種方式也有一個(gè)優(yōu)點(diǎn)：對(duì)于一些目標(biāo)指向性明確的用戶，例如他就直接只關(guān)注第XX頁的記錄，這個(gè)時(shí)候就可以通過分頁條基本上一步就過去了。技術(shù)上的實(shí)現(xiàn)，我更多的是傾向于你所列的第二種方法。對(duì)于有分頁需求，這種方法其實(shí)算不上耦合很緊，因?yàn)榭傢摂?shù)和當(dāng)前頁的數(shù)據(jù)記錄都是用戶所需要的信息。而且一次交互就能實(shí)現(xiàn)，簡(jiǎn)單直接。再說網(wǎng)絡(luò)速度你知道滴，交互能少些還是少點(diǎn)好。
2、第二種，有點(diǎn)類似你所說的第一種方法，只提供當(dāng)前頁的記錄信息，但只保留一次交互，不提供總的頁數(shù)信息。當(dāng)用戶瀏覽到最后一條記錄時(shí)，再滾動(dòng)條下滑時(shí)會(huì)繼續(xù)加載下一頁的信息，也就是前端所說的瀑布流。這種方式與第一種方式相反，符合那種只關(guān)心前XX條信息的用戶需求，但對(duì)于目標(biāo)指向性明確的用戶就悲劇了，用戶得不同的下滑滾動(dòng)條加載下一頁，而且還不知道什么時(shí)候該結(jié)束。這種方法的技術(shù)上實(shí)現(xiàn)就簡(jiǎn)單了，一次服務(wù)調(diào)用提供當(dāng)前頁的記錄信息即可。
3、第三種，綜合第一種和第二種方式。先提供瀑布流的方式的方式，滿足那種只是隨便瀏覽，只關(guān)注前XX記錄信息的用戶。當(dāng)加載到一定條數(shù)的時(shí)候，就不再采用瀑布流了，而是轉(zhuǎn)為分頁，滿足目標(biāo)指向性明確的需求，跳到自己關(guān)心的那一頁。新浪微博Web版就是采取這種方式實(shí)現(xiàn)的，第一次只加載20條記錄，當(dāng)瀏覽到最后一條再下滑滾動(dòng)條時(shí)，繼續(xù)加載20頁，兩次加載完畢后，如果用戶還想記錄關(guān)注，那提供一個(gè)分頁條，其中每頁包含40條記錄，當(dāng)前已加載的40條記錄就默認(rèn)為第1頁(憑印象寫的，可能和新浪微博的實(shí)際采用方式有出入，如有出入請(qǐng)忽略之，另自行查證)。技術(shù)上這種實(shí)現(xiàn)相比第一種和第二種相對(duì)復(fù)雜一點(diǎn)，但用戶體驗(yàn)好很多。只是在默認(rèn)第一頁的時(shí)候把一次交互拆分為兩次，后續(xù)的就是你所描述的第二種分頁方式。
一切的一切，都是基于你的需求所做取舍，自己權(quán)衡利弊吧，技術(shù)上實(shí)現(xiàn)不應(yīng)該成為瓶頸，只是為滿足需求。
添加回答
舉報(bào)
0/150
提交
取消