グリッド内のデータをどのように扱うかについて、大きな議論があります。まだサーバーサイドグリッドまたはJavascriptグリッドを使用する必要がありますか？
サーバーサイドグリッドは、サーバーから簡単にバインドしてAjax/Notで更新することができます。また、Webサービスを呼び出してJavascript/htmlグリッドを作成するJavascriptのみを使用する方もいます。
生産性、テスト容易性、保守性の面でプロフェッショナルな視点から、
WebForm .Net 4.0とJqueryを使用しています。
私は間違いなくJavaScriptのコントロールを言うでしょう。
私はMicrosoft、Telerik、および他のすべての人が、オープンソースコミュニティー（主にjQueryベースのソリューション）よりはるかに劣っていると思っています。
AJAXと非同期リクエストは長年にわたって存在していますが、最近はMicrosoftがMVCを適切にサポートするために出てきました（そして、私が聞いているところでは、
もう1つの利点は、クライアント側のコントロールがサーバー側のコントロールよりもはるかに多岐にわたっているため、あなたに合ったコントロールを見つけることができます。すぐに使えないものを実行する必要がある場合は、オープンソースです。あなた自身で実装することができます。
私はjqgridを使用しています。私はそれに非常に満足しています。
私はあなたと同じシナリオでした。結局、データをバインドするのは非常に簡単だったので、私はサーバー側のGridViewを使いました。一方、GridViewを更新するたびにページをリフレッシュすると面倒だったので、最終的にAJAXの更新パネルで非同期のポストバックを使用してすべてをスムーズに保ちました。
古いファッションのポストバックやフルページのリロードは誰も好きではないので、Ajaxは答えになるでしょう... ASP.NET MVCは、ポストバックとウェブフォームのページライフサイクルの古い概念さえもないので、
DevExpress MVCGridViewの拡張機能やTelerikの機能を使用すると、同じ状況になりますが、ExtJsのような完全なjavascriptソリューションは、クールで高速ですが、重要なセルマージをサポートしていないようです私たちのための機能。
これまでにこの引数がありました。
aspグリッドの大きな点は、基本的には並べ替え、ページングなどでボックスの外で作業することです。そして、私は個人的に嫌なjavascriptを扱う必要はありません。しかし、彼らはもっとブルートフォースの解決策です。私は、ひどく非効率的にポストバックし、DBからデータを取得し、再バインドし、ページを再構築し、列をソートするためだけに戻すことを意味します。
グリッドを中心としたUpdatePanelを使用しても、ワイヤを通過するデータが大量になり、テーブルを並べ替えたりページしたりするだけのデータアクセスが発生する可能性があります。
JavaScriptは醜いですが、はるかに効率的です。 1つは、ソート（および場合によってはページング）をクライアント上で非常に迅速に処理できるため、サーバーの負荷が軽減されます。しかし、サードパーティのJSテーブルコンポーネントを使用しない限り、カスタム機能を記述する必要があります。
もう1つの選択肢は、ASPグリッドを使用することですが、その場でjavascriptを使用して機能を変更します。そうすれば、サーバー側のコードでも簡単なバインディングとテーブルの生成を利用できます。
ASPグリッドをそのまま使用することにしました。パフォーマンスの問題が発生した場合は、アプローチを変更します。しかし、最小限の頭痛で何かを素早く完了させるために、組み込みのコントロールを打ち負かすことはできません。