Demo位址：https://gitee.com/530521314/Partner.TreasureChest/tree/master/Pagination/
本文位址：https://www.cnblogs.com/CKExp/p/9218904.html
分頁功能很多已有的很完美的插件或是第三方應用包都能夠完美實作，我在此利用了一些前端插件來完成分頁功能。
前端的Bootstrap Paginator插件完成前端分頁數字之類的切換展示；
利用knockout.js插件完成分頁資料的綁定；
在後端，利用asp.net core mvc 完成分頁資訊的接收和處理工作。
完成對已有資料的分頁功能，不帶條件查詢。
首先，一上來便是完成資料綁定工作：
頁面剛展示的時候得有分頁資料吧，可以在當頁面展示的時候，資料也帶過來了，也可以頁面展示後，再通過ajax去背景調用，我選擇後者。
在頁面啟動時，調用該函數完成初始化頁面資料。
分頁資訊(目前頁面，頁面展示資料條數)帶過去，背景根據分頁資訊完成資料查詢，并獲得總的記錄條數用于前端頁面計算總頁數。
根據分頁資訊查詢也就搞定了，當點選底部的頁面碼的時候得改變目前分頁資訊，然後要切換目前分頁資訊所對應的資料出來，在Bootstrap paginator插件中，點選頁面碼有一個函數onPageClicked，點選具體的某一頁後，根據參數page獲得頁面，改變目前展示的頁面碼數字，并對分頁資訊修改，然後再次調用ajax獲得新資料。
至此，簡單分頁功能便搞定了，在此實作中，偏重于前端實作分頁邏輯，背景隻是取得相應的資料。
複制一份簡單分頁後，改造下加入一個根據書名條件項，查詢後完成分頁功能。
首先加入書名綁定，在此用了兩個書名，第二個是有目的性的留着，也隻是我的了解，條件查詢後，如果底部展示有多頁，那麼我在點選每一頁的時候，我的查詢條件不能動吧，基于此考慮的。
資料查詢部分改動不大，主要是把查詢條件加入進來，是以隻改動data參數即可。
前端Html部分加入單條件項，以書名為例，查詢按鈕綁定點選後的觸發函數
點選查詢後執行函數，将目前頁面重置為1，查詢資料，并記錄該次查詢的查詢條件。
查詢完畢，然後假設底部還存在很多頁面碼可以選擇，當我們點選頁面碼的時候，因為查詢條件仍然存在，我們點選後仍然會完成分頁功能，但是！！！
當把查詢條件清空，比如在此demo中，把書名置空，此時不點查詢按鈕，而是直接點選頁面碼，那情況會如何呢，查詢條件已經沒了；
或是說查詢條件為空時，輸入查詢條件，不點查詢按鈕，直接點選頁面碼；
這都是不合理的情形，點選頁面碼的時候肯定得保證原查詢條件的存在，至少我是這麼想的，或許您有更好的建議，請告訴我，十分感謝。這也就是我在之前設定了一個監控對象bookNameBackup的原因，備份查詢條件，防止點選頁碼切換時查詢條件變更的情形。
前端已經改好了，然後進入後端來改一下，先對條件判空處理，然後執行相應的邏輯。
單條件查詢分頁功能也就搞定了，查詢和點選頁面碼所執行的邏輯是不一樣的，雖然都調用到了最終的資料查詢方法，但是對于條件的處理是不一樣的。
對單條件查詢分頁下多加入幾個條件，進入到多條件查詢，變化其實不大，隻是為了友善管理如此多的查詢條件，改成了以對象形式管理
首先綁定查詢對象資訊，該對象中包括了三個查詢條件，書名，作者，出版社，仍然設定一個備份對象，原因和單條件查詢下是一樣的。
頁面的查詢條件多了，通過queryItemEntity為字首展示，也友善維護
查詢條件改動，也使得資料查詢部分的條件改變了，将查詢條件整體封裝，而不是零散的傳遞，改動之處加入了第三行将ko上的查詢條件資訊轉換為JS對象和改變了參數data的值。
點選按鈕查詢處的邏輯還是沒有改變，仍然是查詢記錄并将查詢條件備份，用于分頁控件中頁面碼的點選函數。
對于前端來講改動并不是很大，無非是将查詢條件封裝一下，同樣後端的改動隻是多個查詢條件的過濾，依次比對三個查詢條件是否為空，并挨個去完成查詢的過濾。
多條件查詢分頁的效果展示
至此，查詢功能算是簡單完成了，或許還有漏洞地方，沒有發現，特别是邏輯漏洞，防不勝防，望多指教，感謝。
設計一個小Demo一方面是對分頁功能進行一下總結，以防自己若幹天或是若幹年後還需要，可以回來看看，一方面也是如果有需要的朋友可以加快編碼和設計的過程。
碼雲上存放Demo的位址：https://gitee.com/530521314/Partner.TreasureChest/tree/master/Pagination/