現在のページネーション実装の設計に関する質問

asp.net mvcのページネーションの実装を具体的に確認しましたが、実装にはあまり効率的でないものがあると本当に感じています。

すべての実装の最初に、以下のようなページネーション値を使用します。

public ActionResult MostPopulars(int pageIndex,int pageSize)
{

}

私が間違っていると感じることは、pageIndexとpageSizeが完全にPaginationクラスのメンバーでなければならないことです。そうでなければ、この方法は非常に機能的な方法に見えます。また、アプリケーションの階層で不要なパラメーターパスを簡素化します。

2番目は、以下のインターフェイスを使用することです。

public interface IPagedList<T> : IList<T>
{
    int PageCount { get; }
    int TotalItemCount { get; }
    int PageIndex { get; }
    int PageNumber { get; }
    int PageSize { get; }
    bool HasPreviousPage { get; }
    bool HasNextPage { get; }
    bool IsFirstPage { get; }
    bool IsLastPage { get; }
} 

ページネーションを別のアクションにルーティングする場合、アクション名またはコントローラー名をカプセル化するための新しいビューモデルを作成する必要があります。別の解決策として、このインターフェイスモデルをビューに送信し、ページャーメソッドでパラメーターとしてハードコードされたアクションとコントローラーを指定しますが、ビューは1つのアクションに厳密に依存しているため、ビューの完全な再利用性が失われています。

別のことは、彼らがビューで以下のコードを使用することです

Html.Pager(Model.PageSize, Model.PageNumber, Model.TotalItemCount)

モデルがIPagedListである場合、なぜオーバーロードメソッドを提供しない@Html.Pager(Model)か、さらに優れたメソッドを提供しないのでしょう@Html.Pager()。この方法でモデルの種類を知っていることをご存知でしょう。Model.PageNumberの代わりにModel.PageIndexを使用していたため、間違えていました。

もう1つの大きな問題は、IQueryableインターフェイスに強く依存していることです。データ層でIQueryableを使用していることを彼らはどのように知っていますか？私は、ページネーションの実装の永続性を無知に保つコレクションだけで動作することを期待していました。

ページネーションの実装に対する私の改善アイデアの何が問題になっていますか？このようにページネーションを実行しない理由は何ですか？

user8685が述べたように、あなたのインターフェースは既存のMVCのものと原則に対して冗長なようです。

これを試してください：ページインデックスなどのIPagedListから必要な情報は、ビジネスロジックレイヤーに実装し、サーバーにフィードバックし、そこで安全にキャストおよび処理できる汎用モデルを通じてビュー/ページにフィードする必要があります。どうして？ここで収集しているのは、情報システムへの入力であり、UIよりも下位のレイヤーに属しているためです。

この方法は最善の方法ではない可能性があり、確かに最速ではありませんが、抽象化とデータアーキテクチャの観点から本当に必要なものを見やすくし、冗長性を取り除くのに役立ちます。

また、既存のヘルパーは、単純な使用にはオーバーヘッドが大きすぎることが多く、時には全体像をわかりにくくします。

このIPagedListやヘルパーを使用したことはありませんが、これは私の考えです。

これMostPopular(int pageIndex,int pageSize)は、明示的なインターフェイスの記述です。MostPopularのページのみを返します。どのページとそのサイズを明示的に教えてください。

コントローラーメソッドを作成した場合MostPopular(IPagedList<T> page)、インターフェイスはさらに混乱します。コントローラーにアイテムの合計量を伝えていますか？

コントローラーがデータの特定のページスライスを取得すると、通常、アイテムの合計数など、他のさまざまなデータを検出できます。この時点で、そのようなデータをビューに返すことは理にかなっているので、その一部を選択的に使用できます。

これはIPagedListであることを意味しないモデルは、それだけにもなり得るの一部機種（これのプロパティ）。これが、パラメータなしのオーバーロードがない理由です。

IPagedListをオーバーロードとして追加することもできますが、実際のデータ自体を必要としない小さなページャーヘルパーにセット（データのページチャンク）を渡すことになります。ページ/アイテムなどを強調表示できるように、ページ/アイテムの数と現在の位置を知る必要があります。ヘルパーは、その仕事をするために知る必要があるよりもはるかに多くを伝えます。現在の仕組みでは、カップリングが低くなっています。これは良いことです。

クライアントがページ番号を要求し、クライアントが変化する可能性が最も高いものは、ページサイズだと考えます。

public ActionResult MostPopulars(int pageIndex,int pageSize)

これはかなり賢明な方法です。（最初、次、前、最後）の数字が使用されているバリエーションを見てきましたが、実際には "pageIndex"と言うのは厄介な方法です。

繰り返しますが、ページサイズは、モバイル、ポータブル、大画面ワークステーションの異なるデフォルトを取得する必要があり、さらに多くの場合、エンドユーザーが構成するアイテムの数を選択できるようにする必要があります。ページ。

これにより、MVCフレームワーク内で多くのパラメーターが渡されることがわかりますが、ページングの概念全体がMVCを破ります。ページングが機能するためには、ビジネスロジックがプレゼンテーションについて知っている必要があるため、常に煩雑になります。