MS_GridViewAndjQGrid

GridViewとjQGrid

• 戻る（Grid）
  • Gridのヘッダ固定方法
  • GridViewとjQGrid

概要

GridView と jqGrid のどちらを採用するか？

技術組合せ

GridView（ListView）

• ソート＆ページング

  • サーバ：対応可能
  • ローカル：対応不可能

• 更新処理：得意（GridView の table 上の input を POST するだけ）

jQuery

• ソート＆ページング

  • サーバ：

    • JSON のデータを返す WCF や WebAPI 側で対応
    • ページングなどを使用して、大量データでも問題無く扱う事が出来る。

  • ローカル：

    • jQuery（jqGrid）で対応
    • ページングなどを使用して、大量データでも問題無く扱う事が出来る。

• 更新処理：
  苦手（WebAPI が相対的に難しいので、参照処理を書くので息切れするので）

移行メモ（誤記）: 移行元の「大量データでも問題無く書く事とは出来る」を、
文意から「大量データでも問題無く扱う事が出来る」と読み替えて記載した
（2 箇所）。

組合せ

GridView（ListView）＆ jQuery（jqGrid）の場合の使い分け。

• 更新処理
  • 有り：GridView（ListView）
  • 無し：jQuery（jqGrid）

要件的選択

更新処理の有無

更新処理があるグリッドは、
GridView（ListView）＋ DataSet を使用した方が開発が容易。

ローカルソート＆ページング

• jQuery（jqGrid）を使用する。
• 大量データの場合は採用できない。

サーバソート＆ページング

大量データの要件にマッチする。

GridView（ListView）

ObjectDataSource と組み合わせると簡単に実装できる。
更新処理がある場合はコチラを採用したほうが良い。

• ObjectDataSourceとDataPagerを使って、
  ListViewにサーバーサイドページングを実装 | 84zume Works
  http://84zume.wordpress.com/2011/07/18/objectdatasource%E3%81%A8datapager%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%80%81listview%E3%81%AB%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E3%83%9A%E3%83%BC%E3%82%B8%E3%83%B3%E3%82%B0%E3%82%92%E5%AE%9F/

• サンプル
  https://github.com/OpenTouryoProject/OpenTouryo/tree/develop/root/programs/CS/Samples/WebApp_sample/WebForms_Sample/WebForms_Sample/Aspx/sample/3Tier

  • ProductsConditionalSearch.aspx
  • ProductsConditionalSearch.aspx.cs

• ポイント

  • GridView（ListView）だと画面再描画になりますが、
    サーバ・ソート＆ページングであれば性能的に問題は無いと思います。
  • 画面再描画もアップデートパネルで何とかなりますが、
    この選択は開発者の好みで決まるように思います（jQuery の方が "流行っている"）。

jQuery（jqGrid）

• サーバーからデータを取得する。以下は JSON のフォーマット。

  • wikiretrieving_data - jqGrid Wiki
    http://www.trirand.com/jqgridwiki/doku.php?id=wiki:retrieving_data#json_string

• 以下は jqGrid のサンプル。

  • jqGrid Demos
    http://www.trirand.com/blog/jqgrid/jqgrid.html

  • OpenTouryoProject/SampleProgram/・・・/jqGridandWCF
    https://github.com/OpenTouryoProject/SampleProgram/tree/master/ASPNET/WebForm/jqGridandWCF

補足（この対立軸は「前提そのもの」が変わった）: 本ページの整理
（更新あり → サーバ側コントロール、更新なし → JS グリッド）は、
当時の判断としては的確である。ただし前提が二重に変わった。

【変化① Web Forms 系が新規開発から外れた】★
   ・GridView / ListView / ObjectDataSource / DataPager は
     いずれも【ASP.NET Web Forms】の資産
   ・Web Forms は【.NET Framework 4.8 が終着点】であり、
     .NET Core 以降には【移植されていない】
     → 新規開発では選べない
   ・後継として Microsoft が示すのは
       ・【Blazor】（サーバ側コントロールの発想に最も近い）★
       ・ASP.NET Core MVC / Razor Pages ＋ JS グリッド

【変化② jqGrid が商用有償化した】★
   → 詳細は [Gridのヘッダ固定方法](MS_GridHeaderFix) を参照

【本ページの判断軸は今も生きている】★
   「更新処理があるなら、サーバ側で完結させた方が楽」
   という洞察は、技術が変わっても妥当である。

   現在での読み替え
     ・更新処理あり・社内業務システム
         → 【Blazor Server + QuickGrid / MudBlazor DataGrid】
           C# だけで書け、状態管理をサーバに置ける ★
     ・参照中心・大量データ・凝った UI
         → API（ASP.NET Core Web API）＋
           【AG Grid 等の JS グリッド】★
     ・両方必要
         → 一覧は JS グリッド、
           編集は別画面（モーダル）に分離するのが定石

【「更新処理は苦手」の中身】
   原文が「WebAPI が相対的に難しい」としている点は、
   具体的には次の作業が増えることを指す。
     ・変更行の【差分検出】（追加/更新/削除の区別）
     ・【楽観的同時実行制御】（行バージョンの突き合わせ）
     ・【一括更新のトランザクション境界】
     ・エラー時の【どの行が失敗したか】の返却と表示
   → これらはサーバ側コントロール（DataSet）が
     内部で面倒を見ていた部分であり、
     SPA 化すると【自前実装になる】★
   → 現在は EF Core の変更追跡 +
     DTO の差分送信で組むのが一般的

移行メモ（Tags の欠落）: 移行元にはページ末尾の Tags 行が
存在しないため、内容に基づき付与した。

---

Tags: 移行, .NET開発, ASP.NET Web Forms, その他、開発の色々