なんか英語だとかっこよく見えるけど、普通にページ切り替えのこと。 LINQ使ってIQueryableなデータをページ切り替えできるようにするってばよ。
ASP.NET MVC: PagedList<T> : Rob Conery
ここのソースをそのまま流用してもよし。少しいじるもよし。自作するもよし。 結局はこういう形に落ち着くはず。 IPagedListとインターフェースを定義しておくのにも訳があり。
ASP.NET MVC - Pagination View User Control | Code-Inside Blog International
↑こういうページ切り替えコントロールを作成する時に、インターフェース渡しにしておくことで、型に依存しなくて済むから。IPagedListを受け取るようにコントロールを作っておけば、どんな型でも関係なく、ページに関する情報のみ取得できるでしょ。
上記、いずれもASP.NET MVCって書いてるけど、LINQだからMVCかどうかは関係ないと思われる。 ところで、ASP.NET MVCに限らず、AJAX的なページの部分更新を行う場合って、一般的な方法というのがあるんだろうか。 今はMVCで作ってるとはいえ、MVCに限った悩みとは思えず。 特に、リストでデータを持ってる場合とか。
<div id="container"> <ul id="list"> <li id="item1">Data1</li> <li id="item2">Data2</li> <li id="item3">Data3</li> </ul> </div>
こんな感じのHTMLを持ってるとして、ulにliを1つ追加するような処理ってどうしましょうか、っていうね。 １．ページ全体更新。 ２．ul全体(ulタグ込み)を取得して、divのinnerHTMLを書き換え。 ３．追加対象のli(liタグ込み)を取得して、ulのinnerHTMLに書き足し。 ４．追加対象のliの中身(liタグ無し)だけを取得して、document.createElement('li')のinnerHTMLに値を入れた後、ulにappendChild。 ５．JSONか何かでデータだけを取得して、クライアントサイドですべての表示要素をcreateElement。
上からデータ量の多い順(３と４は誤差の範囲だけど)。 １はそもそも、ページ全体なんだからAjaxとか関係なし。 ５はサーバーサイドでのビュー定義がまったくもって役に立たなくなりかねないし、JavaScriptコードが多すぎて面倒。Google Gearとかだとこの方法じゃないとつらいと思われるけど、今回は対象外としたい。 ２・３・４のどれを選ぶのが妥当なんだろうか。 ２の場合、ページの初回表示の時に使用するであろうコントロール(ASP.NETだとUserControlだし、Railsならpartialか)を、 Ajaxの結果としてResponse.Write。データ1個を返すだけだったりしても、リスト全体が対象になる分、データ量は増えるけど処理は簡単。 ３と４の場合(ほとんど一緒)、リスト全体を表現するコントロールと、リストアイテムのコントロールに分けて作っておけば、ページ出力の場合と、部分出力の場合でも、それほどコード量に差が出てくるわけでもないんだけど、データ量は少なく済む。 んじゃ、常に３か４でいいのか？ってことになるんだけど、結局4だとcreatElementしなきゃいけなくて、コードがめんどっちくなる。３はというと、結構いいんだけど、サーバーサイドのコントロール階層が少し深くなって見通し悪しな気がしなくもなく。 でも結局は、２と３の組み合わせ(適材適所で！)になるんだろうとは思うけど。 今はずっとASP.NET MVCで、PostBack方式でのWebFormsを全然使ってないんだけど、サニタイズ気をつけてれば、こっちのほうが自分の思考にあってて作りやすい気がしてならない。 それもこれも結局は好みの問題なんだろね。
ハァ～。NHLプレーオフ生で観たい。デトロイト今年こそやってくれそうだし。
