思緒良久，最後還是決定記錄一下遇到的坑，畢竟被 『折磨』 了三天，關於分頁，這個話題，我一開始時拒絕的，因為真正接觸專案的時候，才發現每個框架都會封裝一套自己的分頁，畢竟相同風格的專案是不常見的，而在學校書本上講的那套 web form分頁的那套說辭也out 了，學校接觸的mvc 不多，現在專案趕上，就來談談分頁的坑。一般如果自己寫底層分頁的話，無非就是，幾個輔助類，然後乙個pager的擴充套件類，再自己封裝下樣式，如果不熟悉的話，比如說我，還是用網上開源的吧
ef 誤區
1. 一直以來，自己的無知，以為用ef的code first思想 來自動生成資料庫，資料表，實在是太繁瑣，自己也就寫過一兩個測試表玩玩，要是真正開發的時候，如果不是深入了解過ef的話，實在是費勁。然而，ef是分情況的，至少我是這麼認為，有表或者無表。當資料庫已經存在的時候，仍然可以使用ef
2. 當存在資料表的時候，以往只知道建立資料庫實體類，然後生成一大堆東西（t4模板），如果不這樣話，自己手寫規則，這樣一來，不了解規則的話寫起來同樣比較費勁，然而，可以使用codefirst來直接生成實體類，
這樣下來，對比左邊和右邊就顯得簡潔多了，看起來也清爽
（注：如果不是最新的實體框架，輸入命令 install-package entityframework）
3. 總以為凡是用了實體類就 等於一下子把資料全部查詢出來，對於千萬級的資料，用ef來做翻頁，效率低的很。殊不知，ef實體是對映到資料庫中，並沒有做全部查詢，建立實體物件之後，lambda是做延遲載入的，當使用tolist() 方法之後，才算是在查詢資料庫
拋去以上錯誤觀點之後，當呼叫開源的分頁外掛程式的topagelist（pageindex，pagesize）方法時，實際上的效率並不比 sql（儲存過程） 訪問資料慢多少，另外linq的 skip() 和take() 方法同樣也可以起到分頁的效果。 對於ado.net 訪問資料來說，一般思路是：
public actionresult sqllist(int ? id =1以上**可以看出，先得到每頁的查詢結果，然後 反射成list物件，此處省略反射的公有方法1000行。。。)
如果使用的是ef的話，那麼**如下，可見是如此的簡潔明瞭
public對於分頁前台的實現actionresult index(int id = 1)
easyui
bootstrap
jquery、ajax
自己封裝一套也可以，畢竟翻頁的風格是跟著專案介面的風格走的，比如說我當前的專案，就是純手寫前台js，關於翻頁，終究也就是這麼回事，主要就是有時候沒有明白乙個知識點，或者存在誤解的時候，真真是只有自己心裡明白，問別人，提問，總感覺無法清楚的表述自己的問題，導致一時會卡很久，有些東西時間、經歷沒到，真是無法理解，好多點也都是畢業後，才潛移默化的理解了不少以前硬背也沒死記住的知識。同樣，這這裡，要感謝那些積極回答我博問的園友。
---時間煮雨，雨落前堂
UITextView的那些坑
坑1 ios7及以上的版本上，uitextview出現這樣的問題 彈出鍵盤時，沒輸入任何文字，但是游標位置不是在最上方。解決方案 ios7以後新增了乙個屬性automaticallyadjustsscrollviewinsets，將其置為no即可。別忘了加版本判斷。if ios7 and later...
string的那些坑
坑一 typedef struct st st st test st malloc sizeof st st m1 hello 除錯這段 你會發現最後一句報段錯誤。為什麼呢？string本質是個類，而malloc不知道要呼叫string的建構函式去例項化m1，結果導致m1這個物件實際不存在，去用它當...
Flask SQLALCHEMY 的那些坑！！！
if request.method get 接收前段傳遞過來的使用者id uid request.args id 根據id將對應的使用者資訊讀取出來 user db.session.query users filter by id uid first print user user user1 db...