asp.net - ビューステートに保存されているDataTableをリストに変換しています悪い選択肢？

Question

私は新しい仕事を始めたばかりで、多くの場所でうまくいかない悪夢のWebForms.net4.0プロジェクトを継承しました。

ViewStateにDataTableを保存しているユーザーコントロールがあります。コードは、コード全体の列をインデックス番号で参照しているため、完全に読み取り不能になっています。列を名前で参照して読みやすくすることはできますが、リストに分割したいと思います。

以前の開発者はリストをViewStateに保存しています。これは、変更をデータベースに永続化できないためです。データを読み込み、営業担当者が価格を変更してから、情報をXML形式にプッシュして、で販売注文フォームを生成します。 PDF。そのため、一時的に保存するメカニズムが必要です。

ゼロから始めるという贅沢があれば、JSONでデータをプルダウンし、すべてクライアント側で実行しますが、まだその贅沢はありません。

1. DataTablesを使用してから長い時間が経ちましたが、これをViewStateに配置するのは良くないと確信していますが、正しいですか？ViewStateにどのような負荷がかかるでしょうか。44列、通常は約25行を見ています。：s

2. 次に、DataTableではなくViewStateにリストを配置することに大きな違いがある場合、または両方が互いに同じくらい悪い場合、現在の位置から切り替えても害はありませんか？

3. 3番目の質問、行の更新はViewState DataTableで自動的に更新されますが、それはリストと同じでしょうか？

4. 最後に、アドバイスをさらに詳しく調べます。この情報（できればリスト）サーバー側を保存するのに最適な場所はどこですか？セッションまたはキャッシュの方が適していますか？

Answer 1

1. あなたは正しいです。DataTableをViewStateに保存するのはひどい考えです。

2. リストをViewStateに保存することは依然として悪いことであり、DataTableを保存するよりもわずかに優れている可能性があります。

3. 「更新はDataTableで自動的に行われる」とはどういう意味かは明確ではありません。ViewStateからDataTableを取得し、プログラムで更新を適用しない限り、これが当てはまるとは思えません。リストを使用する場合も同じことを行う必要があります。

4. セッションの方がおそらく優れていますが、スケーラビリティの問題が発生する可能性があります。率直に言って、私はそれをSessionに保存しますが、OutofProc状態プロバイダーの1つを使用することを選択します。このように、シリアル化されたDatatableがリクエストごとにクライアントに送信されることはなく、ページサイズが非常に大きくなり、SQLサーバーやASP.NETStateServerなどのさまざまな場所にこのシリアル化されたデータを保存するオプションが提供されます。